behaviour of dialog windows
A Logo programming environment for Microsoft Windows
Brought to you by:
david_costanzo
Menu
▾
▴
#37 behaviour of dialog windows
I'm still finishing Little Helper which has walked a long way since. Seen from outside, it essentially appears as a dialog window containing a textfield, a listbox and a lot of buttons arranged in a special order. Now I have two questions about this dialog window as a whole. These may pertain to any coded dialog window.
-
Is it possible for the program, to know whether or not the dialog window has been moved by the user since it was addressed by the programm the last time? An answer to this would suffice for me, but somebody else would possibly like to know, to which position the dialog window has been moved. For the main window MACHINE answers all questions, but there seems to be no equivalent function for an internal dialog window. So my question is: How can I as advocate of my program know that our dialog window has been moved (and perhaps additionally know, where it is now)?
-
I'd expect from a modal standard tool like MESSAGEBOX that it forces its whole environment to wait, until the user has answered to it, so that no action around can take place. But to my surprise even a pretty big coded dialog window like Little Helper seems to be not restricted at all, but can be clicked successfully by the user while the messagebox is open und waiting. At the same time the whole commander appears paralyzed. When the initiated actions will be performed, a lot of things can happen. As an example, the messagebox can be covered from view by the dialog window while it's still active and paralyzes a lot of things, especially the commander. Being confronted with this, an inattentive user would presumably take this as some kind of unexplainable error. I could solve this problem programmatically and would be ready to do it, if I knew for sure that this behaviour is okay and in compliance with the rules of FMSLogo. So my question is: Is this observed behaviour in compliance with the rules of FMSLogo?
1) Yes, it's possible by using DLLCALL. First, you must determine the HWND of your dialog, as with FindWindowWEx. Then you get the size/position with GetWindowRect. You can determine if it's been moved by comparing the size/position of two successive calls to GetWindowRect. You can look at uiautomation.lgo (sourceforge.net) in the FMSLogo test automation for example of how to use DLLCALL to call these functions.
2) This has nothing to do with the size of a dialog box but whether or not a dialog box is modal. Dialog boxes created with WINDOWCREATE are not modal and so allow FMSLogo to process instructions. Dialog boxes created with DIALOGCREATE are modal and do not allow FMSLogo to process instructions. This is described in the manual.
If a user obscures a modal dialog box, they do, indeed, create problems for themselves. This is as true for FMSLogo as it is for any other applications. Modal dialog boxes should be reserved for when your program absolutely needs input from the user to continue. If the answer is non-urgent, prefer non-modal dialog boxes. For example, the "Set -> Pen Color" dialog box was modal in MSWLogo and it's not modal in FMSLogo because the answer isn't urgent.
Thank you for the answer. You said it clearly, and I think, I have a purely FMSLogo-based workaround to handle it. What surprised me is the insight that I will always to have to control thoroughly the interaction of two windows, even when both of them come from WINDOWCREATE und thus are not modal. I think that urgence is not the only reason for preference. I have to be careful all the time. Concerning DLL-programming I'll mark your proposals for occasions to come.