|
Anaristos Sorcerer
Joined: 17 Jul 2007 Posts: 821 Location: California
|
Posted: Tue Jun 24, 2008 6:25 am
CMUD 228 - Lock up during use of #PROMPT |
I did the following:
Created a dialog box using #PROMPT.
While the dialog box was open, I gave focus to the Settings Editor. In an attempt to look for the proper value to insert into the dialog box (I was running a test) I noticed that the vertical slide was not operational. When I tried to minimize the Editor, I found the window buttons were also out of service. When I clicked back on the session window, I found that focus could not be restored to the window, though the MUD output continued to scroll.
The behavior of the session window is reasonable since that is what one would expect when a modal dialog box is active. What is unexpected is that I was able to give focus to the Settings Editor (this should not been allowed) or that once focus was given to that window that CMUD forgot who should have focus. In other words, the Settings Editor window behaves as a "always on top" window hiding the dialog box. Since I cannot dismiss the modal box (no access to the buttons), CMUD is effectively locked and the only way to recover is to re-start. I suppose that if the Settings Window were small enough so that the dialog box buttons remained accessible, this problem could be bypassed.
Be that as it may, IMO once the #PROMPT command is issued, focus must remain on the modal box and it should not be delegated.
EDIT: Further experimentation with this problem showed that by giving focus to a foreign window and then returning to CMUD, the dialog box would move on top and become accessible. |
|
_________________ Sic itur ad astra. |
|
|
|
Tech GURU
Joined: 18 Oct 2000 Posts: 2733 Location: Atlanta, USA
|
Posted: Tue Jun 24, 2008 3:44 pm |
I think this has been discussed generically before... I believe there's not too much that Zugg can do because it's more a function of Windows handles modal dialog boxes and the Stay On Top option and not necessarily something with CMUD.
|
|
_________________ Asati di tempari! |
|
|
|
Dharkael Enchanter
Joined: 05 Mar 2003 Posts: 593 Location: Canada
|
Posted: Tue Jun 24, 2008 4:16 pm |
There must be something he can do since one doesn't usually have this problem with other programs that use modal dialog boxes.
|
|
_________________ -Dharkael-
"No matter how subtle the wizard, a knife between the shoulder blades will seriously cramp his style." |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Tue Jun 24, 2008 7:12 pm |
The #PROMPT command does not create a "modal" dialog box. It's a non-modal box which allows you to continue interacting with other parts of CMUD, such as the command line or settings editor. The bug in Windows deals with handling multiple non-modal windows that each tries to set the stay-on-top Z-order.
I have personally seen this problem in lots of other Windows apps. There are many times that a dialog box gets hidden behind some other window and I have to use ALT-tab to get it to the top. So it's not just a CMUD issue. This has been a problem with zMUD for many years and I've never found a good solution. My guess is that Microsoft is unwilling to change how this works because too many applications probably are coded to handle the current particular problems and "fixing it" might break other apps in weird ways.
I was hoping that Delphi 2007 might have some improvements in dealing with this, but it doesn't, so we are back in the same situation that we have been for years with zMUD. |
|
|
|
|
|