Register to post in forums, or Log in to your existing account

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion

Joined: 17 Jul 2007
Posts: 821
Location: California

PostPosted: 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.
Reply with quote

Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA

PostPosted: 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!
Reply with quote

Joined: 05 Mar 2003
Posts: 593
Location: Canada

PostPosted: 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.
"No matter how subtle the wizard, a knife between the shoulder blades will seriously cramp his style."
Reply with quote

Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by