Need some menu pointers

[stanl]

I have an application that uses WB menus. Each menu option has either additional dialogs with options, or a simple Proceed? Yes/No pop-up

In my dialog callback I use the same process for the menu options

Code (WINBATCH) Select Expand


Winhide("~Main Window")   
DialogProcOptions(MyDialog_Handle,  DPO_DISABLESTATE, 1)
subfunction()
WinShow("~Main Window")
DialogProcOptions(MyDialog_Handle,  DPO_DISABLESTATE, 0)
Return(RET_DO_NOT_EXIT)


This works for about 60% of the options - meaning the main dialog is hidden, the menu option is executed then the main dialog is brought back and enabled.

There is no real difference in the behavior of the subfunctions - so should I be hiding the main dialog in each subfunction rather than in the callback?

Hope this makes sense

[JTaylor]

Not sure the "best" way but I usually do my Hiding/Showing as part of the menu code.

Jim

[stanl]

Well I discovered this: the menu options that failed, required some setup (1-4 seconds, ADO queries, INI entries etc..) and I would proceed the sub dialog with a simple BoxOpen("Please Wait","Setting Up").

Seems with the BoxOpen() the hidden main dialog un-hides when the sub-dialog opens. Commented out the BoxOpen...BoxShut and all works. 

Seems like a 'bug'.

[JTaylor]

I don't usually ever do anything with the "Box".

Jim

[stanl]

I don't usually ever do anything with the "Box".

Jim

Then I may be missing a useful alternative. Depending on the user setup, and the time it can take to verify rights, existence of templates, ODBC drivers, often running schemas into a drop down....  I often use Box to inform that activity is going on, to keep them from clicking the exe icon again after a delay.

But I can see your point of perhaps putting the message in the main menu dialog then hiding it in the called snippet. 

[JTaylor]

What I have done upon occasion when the initialization process takes overly long is to initiate it using the Timer event.   This allows the dialog to display which gives the appearance of something happening while everything is initialized.

I do have a few cases still where I wish it didn't take so long but since my main dialog goes away when they click the Menu option they know something is happening.   This is only the case though where the limit on the number of Functions/SubRoutines and variables forces me to create EXEs rather than keep it all as one application.   Hadn't really thought about using the Box for this purpose.    Had thought about launching all my EXEs up front and hiding them and then would only have to Show them when chosen but, as you noted, Hiding/Showing doesn't always work like one wants.

Jim

[stanl]

I still think it's a bug. I forgot to remove a boxshut() in one of the subs and the main dialog unhid.   

[JTaylor]

May very well be.  Obviously undesirable behavior.   I have had similar instances where that Box doesn't do what I want or things I think it shouldn't. 

Jim

[stanl]

I was looking over some old..old code, and at one point I would disable and flash the main dialog while background processing was taking place. Probably there is a strong relationship between the box and any dialog that proceeds it.