I realized when I started doing slightly more with GUI that I had not created an entire screen. That is, all my GUI has been xtrees that sat on top of and were smaller than the text screen behind it. I would like some input if anyone has time, or simply point me in the right direction to read about it. I have been reading, but seem to need more help.

I have created one screen now, but before continuing I would like to know if others have found better ways. I used a dialog box and sized it using as close to a full screen as I seemed to be able to get and then maximized it. That seems to work, but...

1. First, what is the way to create an entire screen? Does everyone use a dialog box and maximize it? That seems to be good, but I don't like the maximize buton that seems to automatically come with it. Can that be gotten rid of?

2. I didn't realize you could use millirows with altpos until I saw Jorge do so. I tried it today and thought I would have 24000 millirows, but it seems to be millirows in altpos units or 1/1000 or the vertical altpos unit. Is this correct?

3. What do you use for check boxes, infld or aui? It seems there may be a slight atvantage using infld in that I think you can type Y/N in the box and can't using aui. I'm not worried about keeping old code, so infld is not a necessity.

It all Jorge's fault!

1. You can create a maximized dialog which has no sysmenu buttons by using ctype MBF_DIALOG+MBF_ALTPOS and cstate MBST_MAXIMIZED.

2. Millirows are always 1/1000 of normal rows, but normal rows come in two types. In the ALTPOS case, they are based on the system font. Otherwise they are based on dividing the main window by 24 (or whatever the current row count is set to). On my laptop 1400x1050 monitor, the entire screen works out to 37 altpos rows high by 107 columns wide. The AUIWIN program in [908,28] will display that information. So, if you wanted to figure out how many ALTPOS rows you had, or alternatively, divide the maximized dialog into a fixed number of rows, you could use the AUI_WINDOW information to make the necessary calculations.

Note, however, that this is a rather non-Windows-like way of laying out screens. More typically, Windows programmers create a dialog layout based on a logical, non-maximzed size (i.e. altpos units), and then let the physical rendering of that dialog which is physically larger or smaller depending on the runtime altpos units (i.e. the resolution and font dpi factors).

But, if you want to work backwards from a maximized dialog, I think you can get the desired results by using AUI_WINDOW to get the various metrics and then divide the screen up, at least vertically, using millirows. (For example, if you wanted 24 logical rows, but there were actually 30 altpos rows on a particular screen, you could use 1250 millirows for each "row".) You might also want to increase the font size at the same time, but this is a bit more complicated.

3. Checkboxes: INFLD vs AUI? It's a matter of preference. If your logic is primarily INFLD-focus (as is usually the case), then it seems easier (to me) to let INFLD handle the checkboxes, because then they act like other INFLD fields. Plus, as you say, the user has the option of using Y/N, 1/0, etc., and your program can treat them the same whether in GUI mode or not.

The AUI approach to checkboxes works better in small dialogs where you don't need to deal with interactivity at the field level. For example, you might want to display a dialog with just a bunch of checkboxes in it, letting the user have free reign until they click the OK button, and only then go and query the checkbox states. In this case, AUI is much easier to implement.

But, if you are dealing with a dialog containing nothing but a bunch of binary (e.g. Y/N or checkbox options) or radio buttons, you might find it easier still to just put them all inside an XTREE. That way you can expand the list without changing the screen layout, letting XTREE handle the scrolling. There is a sample function in the SOSLIB (XTR32BITS) which illustrates this kind of thing.

Note that since XTREE can also handle regular text fields as well, a single XTREE could take the place of dozens of screens full of configuration options.

But take my advice only with a grain of salt (also lemon and Tequila would be recommended). For definitive advice, speak to the Oracle of Porto.

Hi Herman,

After the lesson from the Master in LA, I don't have much to say, but considering that is too late to move you back to text mode, allow me to just add an additional comment about checkboxes.

As the Master say, it's a matter of preference, but my preference goes to AUI because I just put them there and forget them.
Checkboxes works at the same time as an input field and a "button" (I'll use "button" to define a clickable control returning an exitcode), returning both variable value and exitcode (if defined) so, if you want checkboxes to get their values, if you assign your variable to the checkbox cfunc argument you don't need to query the checkbox to get the value, every time you click on the checkbox, the variable value changes and you can use it immediately (w/o the need to query the checkbox with CTLOP_QRYCB).
Note: I think this is not valid in ATE, but considering that you only use Windows, it applies to your case
If you need to do something when a checkbox is clicked (e.g. change other fields values/states), you can handle that by the returned exitcode the same way you do when clicking in a button.
If the problem is to include the checkbox in the tab sequence, that's not a problem, just add the MBF_TABSTOP in the ctype checkbox, and create it in the proper sequence, and you can use the spacebar to switch the value which, in my opinion, is much easier than hitting Y/N or 1/0.

Regards

Hey Herman, i would have responded earlier, but i wasnt finished with my tapioca...

Seems the cure-all for the GUI-itch is spending some time with Jorge! Jorge should probably market a week long GUI resort and spa (with a little programming thrown in!)

Ok, our experience has been very much like yours. First we started with full size screens with gui elements... then we migrated to having all programs inside of a dialog. This does give each program real windows credibility. But, as Jack points out often, very few programs are "full size", even thought some of ours are. So, we make the dialog as big as we need it to be to house the fields, but not necessarily a full screen size.

We have a desktop wallpaper with our logo that sits on the ATE background, to give the user the feel that they are in our program (ZOOM). Then we add/remove dialogs from this desktop. You could pop dialogs right to the windows desktop, but i think that only works well for single task solutions, not systems with many program such as ours ans yours.

The other advantage of placing programs in dialogs is that is is possible to "call" a program from another and have it overlay inside of its own dialog, giveing that windows layer effect. All you need to do tht is xcall amos,"run progname"... then end from the calling program. Of course, you may need to pass a variable or 2 back and forth using common or a file method.

A real easy way to convert programs to dialog format is to replace your call to some banner routine to a routine that creates a dialog instead... an .sbx perhaps.. have u ever used them?

Hope that helps. Have a good weekend.

Thanks for the input. I think y'all have actually confirmed what I was thinking.

Jack, I had used the aui_window call to get the screen parameters and it seemed that an altpos unit was exactly what you described (1000 millirows), but I wasn't sure. Also, I didn't realize that mbf_sysmenu added both the maximize and close buttons. I thought it only added the close button, so I will remove that from my code.

Jorge, I have a screen with a checkbox just as you describe, probably because it was in the test program you wrote for me. I just wanted to see why not use infld and you answered that.

I guess I would still like confirmation that desigining a full screen is best done by setting the row and columns to the maximum millirows and columns and then using mbst_maximize. This seems to work fine, but I don't want to get down the road and go, wow, I wish I had done it that way.

Thanks again.

Sorry Frank, I hadn't seen your post when I started mine. I appreciate your input too. I may need some guidance on the wallpaper issue, but I'll give you time for another tapioca first. Thanks for the suggestions.

My pleasure, though I think my cholesterol is getting high, i better start laying off the tapioca for a bit... (unless you know a good pharamcist who can prescribe me some lipitor! )

Ok, i am going to try and embed a picture here, i havent done it in a while so i kinda forgot, but anyway, its a simple shot of the ATE desktop w/our logo, and our signing program... running inside a small dialog.

To add wallpaper is very easy, the .bmp file must reside on the local pc, and can be invoked as follows:

(there are a host of switches for restoring wallpaper that i coerced Jack into adding, so check the manual for exact details)

LOGO$="%miame%\icons\wallpaper.bmp" ! default wallpaper
?TAB(-10,39);LOGO$;",0";chr(127); ! Loads and saves a wallpaper
?TAB(-1,0); ! Forces wallpaper to background

Hmmm, that wasnt so hard, so here is another shot of our patient program which does fill the entire screen, but shows the benefit of dialog layering.

Thank you Frank. And yes, I might recommend my daughter who is a good pharmacist, but no others come to mind!

Herman - I'm not sure why you are getting a maximize button if you don't either specify the MBF_MAXBUTTON or MBST_MAXIMIZE options. (I don't). A good sample program is XTRA2 - look for MBF_DIALOG and you'll find something like this:

xcall AUI, AUI_CONTROL, CTLOP_ADD, DLGID, "XTREE Dialog Box", &
MBST_ENABLE, MBF_DIALOG+MBF_SYSMENU+MBF_MAXBUTTON+MBF_ALTPOS, &
"", "", STATUS, DSROW, DSCOL, DEROW, DECOL

The result looks like this (note the maximize button):



But if you remove the MBF_MAXBUTTON, you get this (note no maximize button, but you still have the "X" button because of the MBF_SYSMENU):

I was specifying the MBST_MAXIMIZE option. I guess my thinking was that you had to also specify the mbf_maxbutton. Sorry for the confusion.

That's actually a problem. If you specify MBST_MAXIMIZE (to maximize the dialog), then, if MBF_SYSMENU is also set, you end up with a normalize button. (It changes to a maximize button if you click it to un-maximize the window.) There was some reason why I decided that was essential, but I can't recall now what it was.

I gather that you want the dialog to be maximized, and not to allow the user to un-maximize it? I'm not sure why you would care if they wanted to do that, or why, if you're going to deny them the un-maximize option, why you have to give them the X option, but I'm willing to revisit it if there is some good reason.

Herman,

In my opinion, and particularly in your case where, by now, you mostly use dialogs to display XTREE's, you will take advantage on creating not maximized dialogs (smaller than the maximum availble area on the screen) but allowing to MAXIMIZE (using MBF_SYSMENU + MBF_MAXBUTTON).

When you maximize a dialog, all the controls are reorganized in the work area, this is particularly useful in XTREE's considering that, the visible area in the XTREE will increase and the user can see more rows and columns.
So, if you create the dialog in the maximum size and dimension the XTREE accordingly to that size, you are limiting the amount of data visible for the user, on the other hand, if in the future you decide to add columns to the XTREE, probably you will want to adjust the width of the XTREE to fit in the entire dialog.
With the MAXIMIZE option, you give to the user the possibility to see more data, and not necessarily have to readjust the XTREE when adding more columns.

FWIW: I am studying a fine text book that explains the theory behind good GUI and human - computer interaction: Designing the User Interface (4th edition) by Ben Shneiderman and Caherine Plaisant. I studied the 1st edition back in the 80's and it helped immeasurably with 'green screen' design.

Jack, I can't think of any really good reason at this time, so we'll revist if necessary in the future.

Jorge, I guess I want to maximize because I still have a lot (most) users that refuse to even let me change them from 800x600 to 1024x768. I guess most computer users are sitting at a desk close to the screen. Most pharmacists are standing and farther from the screen so it's harder to see. That's the only reason I can come up with!

Tom, thanks for the reference. I've already checked Amazon and they have a lot of these.