Good day -

I have a simple test i am working with, placing dialogs on an empty ATE background. I have specified AUI_PARENTID=0 for each dialog call but ashell seems to be assigning its own parentid for each successive dialog. (see below). I tried the MFB_DLGNOPARENT but as im sure you are aware that places the dialogs on the actual windows desktop. (cool effect but not what im looking for!) How do i get every dialog to be assigned parentid=0?



Form FldId ParId Class Type TabStop Txt CmdLib Func csrow cscol cerow cecol
TELNET 1 0 Dialog 0x20000000 0 3000 3000 15000 41000
TELNET 2 1 StaticText 0x8040040 0 Productivity 1500 2000 2500 51000
TELNET 3 1 StaticText 0x8040040 0 Current Activity 2200 2000 3200 51000
TELNET 4 1 Dialog 0x20000000 0 3000 45000 15000 79000
TELNET 5 4 StaticText 0x8040040 0 Trending 1500 2000 2500 51000
TELNET 6 4 StaticText 0x8040040 0 Current Year vs Last Year 2200 2000 3200 51000
TELNET 7 4 Dialog 0x20000000 0 16000 3000 24000 49000
TELNET 8 7 StaticText 0x8040040 0 Alerts 1500 2000 2500 51000
TELNET 9 7 StaticText 0x8040040 0 Unbilled Charges 2200 2000 3200 51000

PS: Just for fun I replaced the AUI_PARENTID parameter with "" and the result is the same.

PSS: This is a simple standalone program i could send you the source to play with if you like.

Yes, please.

OTW...

Did you try setting parentid to -1 as described in the history notes of the parentid topic ?

It's kind of a hack, but as you've already confirmed, the default value of 0 gives you the default parent, which would be the current modal dialog if there is one.

Was hoping that was it but no-joy...

PS: Actually it worked setting the parentid=0 but my dialogs are still not populating - perhaps you could look at the test program i sent and tell me wth i am doing wrong! tx

According to the Windows hierarchy (as seen by a tool like Windows Spy) setting the parentid to -1 does achieve the result of having dialogs all be a direct child of the main window. You can get the same effect by setting the MBF2_GLOBAL flag. But, I have to admit that still, only the first dialog is visible. I'm not quite sure what the issue is there, or why changing the parent to the desktop works. (Or why your version seems to be working different than mine!) But:

Trying to handle multiple modal dialogs on the screen at once is difficult, if not impossible. If you want multiple dialogs on screen side by side for a visual effect, then you probably want to set the MBF_MODELESS flag. (Modeless dialogs are all independent, which I think is what you want here.)

Hmm well nobody said you could only populate a single dialog on a parent at a time... IAs you know we are using a title-less dialog to achieve a frame effect. Do you have another suggestion to achieve the desired effect w/o using a "dialog"?

Populating them shouldn't be a problem. But I'm less sure about moving the focus between modal dialogs without closing them, since the very nature of a modal dialog is exclusivity. But, as far as the populating goes, I was able to get them all to populate independently by removing the MBF2_STICKY bit from your example. (I'm not sure exactly what the issue with the sticky flag is, or what you were trying to accomplish with it, but that might be the missing link here.)

Hi Frank,
I don't enter in the discussion when I read "ATE" because I don't use it and I know that everything is different from my Windows scenario but allow me to add what I do because my middle name is "multiple Dialogs".
What I do is to open each dialog in a different A-Shell session without the A-Shell screen, the dialog floats around w/o any visible parent.
I don't know if this is possible in ATE and if there are any real problem to open multiple dialogs.

Jack - thanks add modeless has allowed these to all reside on the same background.

Jorge - well Jack correct me if i am wrong but i think 99.5% of all ATE "GUI" related is same as ashell/windows. But however in this case i am using the MBF2_DLGNOCAP option to create frames or containers for certain screen areas.

Who knew that Albuquerque meant "multiple dialogs" in Portuguese!

Although it's true that ATE is just a specialized instance of A-Shell/Windows and therefore mostly behaves the sames as A-Shell/Windows, this might be one area where Jorge's approach wouldn't translate directly. The complication is that the ATE model requires one instance of ATE for each instance of A-Shell on the server side. If you use HOSTEX to launch another instance (as Jorge does), the new instance is going to be sharing the same TCP communication channel with ATE, which won't know how to keep the second instance's GUI environment separate from the first. Instead, if you want multiple instances of the server-side app running simultaneously, you need multiple instances of ATE, each of which has to be initiated from the ATE side. (For extra credit, somewhere on this forum is an old discussion of how to do that -- I think Steve Evans uses the technique.)

But I don't think it would be useful for what I think you are trying to do. Then again, maybe I'm not sure what you're trying to do. I'm imagining that you want to use the multiple dialogs, neatly positioned in a grid, as a layout technique (as opposed to them all acting like independent sessions). From a pure layout perspective, you could just use static rectangular frames instead of dialog, but the MBF2_DLGNOCAP dialog variation gives you some extra capabilities, like the possibility of resizing one of the panels to give it the exclusive focus and then pop it back in position.

I am building this screen:

Is this just a display? Or do you expect to be able to click on one of the numbers to edit it?

From a display standpoint, it might be easiest to create all of those individual cells as static text with a gray background and horizontal/vertical centering. If editing, then we have to look separately on how to make an INFLD/edit box that seems compatible. I guess that's a subject for another thread...

Hi Frank,
That's a nice dashboard, have you tried to replicate that using an XTREE on each panel?
Even those white gaps around each gray block could be reproduced using empty rows and columns, it will be a goldsmith work to get it exactly like the image but I think you will get very close.

As per Jorge, Nice dashboard/display Frank - I was more thinking you be wanting to click on the number/boxes and bring up an xtree containing the full detail/breakdown of the data that calculates the 'box numbers'

Thanks Gents. Some of these buttons are "clickable". Agreed Jorge - some grids would be nice here, but our sales staff has decided that a more "simple monotone" approach is more aesthetically pleasing than throwing a bunch of grids and lines.

FYI, you can easily eliminate the grid lines from XTREE via XTR.SHOWGRID=0, and you can make the lines taller by removing the XTF_VARY bit and bumping up XTR.ITEMLINES.

However, what I don't think you can easily do is add leading between the rows.

So if you really want to achieve that exact look, my bet would be on using static text controls for nearly all of it. If a cell needs to be editable, you can trap the click on it and then put up edit control on top of it. If anything, in a situation like that, you want the edit control to stick out visually, since otherwise it's too easy for the eyes to get lost. I would view that as a feature, not a corruption of the uniform monotone aesthetic.

I think that Jack's "leading between the rows" are my "gaps" so, yes, I think you can get that visual adding empty white thinner rows and thinner columns.
And yes, my suggestion assumes you deactivate the gridlines in the XTREE as described by Jack.

Clever idea! I didn’t even think of that!

Again - the company wants more of a clean web-look. Adding xtrees for me in this case would not accomplish this objective.