In the past I faced this problem and solved it by not destroying the rollout in the open handler.
I was now having this same issue and though it would have been fixed, but it seems it remains there, from Max 2010 to 2018.
Is this a bug or a normal behavior?
Here is a simple test code to reproduce it. After you close the second rollout the Max UI gets locked.
(
try destroydialog ::ro_test catch()
rollout ro_1 "" width:300 height:300
(
on ro_1 open do destroydialog ro_1 -- This seems to cause the UI Lock
)
rollout ro_2 "" width:200 height:110
(
button bt1 "Close Me" pos:[24,32] width:152 height:40
on bt1 pressed do destroydialog ro_2
)
rollout ro_test "" width:168 height:104
(
button bt1 "Press Me" pos:[8, 8] width:152 height:40
button bt2 "Press Me" pos:[8,56] width:152 height:40 enabled:false
on bt1 pressed do
(
bt1.enabled = false
bt2.enabled = true
createdialog ro_1 modal:true
)
on bt2 pressed do createdialog ro_2 modal:true
)
createdialog ro_test
)
WOW! that’s super cool finding…
the first one is the workaround:
rollout ro_1 "" width:300 height:300
(
on ro_1 open do
(
windows.postmessage ro_1.hwnd 0x0010 0 0
)
)
where 0x0010 is WM_CLOSE
… the explanation will be later. i’m a little busy right now. in two words – destroydialog sends message instead of posmessage
Thank you Denis. Posting the ‘close’ message seems to work, although I am not sure if there will be any side effects.
All createDialog() does is to send a close message? I couldn’t find any related code in the SDK.
In the following example, posting the message also fails, but if you put it after the messagebox it works.
(
try destroydialog ::ro_test catch()
rollout ro_1 "" width:300 height:300
(
on ro_1 open do
(
windows.postmessage ro_1.hwnd 0x0010 0 0
messagebox "So far so good!"
)
)
rollout ro_2 "" width:200 height:110
(
button bt1 "Close Me" pos:[24,32] width:152 height:40
on bt1 pressed do destroydialog ro_2
)
rollout ro_test "" width:168 height:104
(
button bt1 "Press Me" pos:[8, 8] width:152 height:40
button bt2 "Press Me" pos:[8,56] width:152 height:40 enabled:false
on bt1 pressed do
(
bt1.enabled = false
bt2.enabled = true
createdialog ro_1 modal:true
)
on bt2 pressed do createdialog ro_2 modal:true
)
createdialog ro_test
)
there shouldn’t be any side effects. because as i know max UI is always in the main thread.
the second question i don’t understand… createdialog doesn’t send close message. it has to send ACTIVATE and SHOW (and another like paint, etc.)
when you press close window button (X) it sends probably PostQuitMessage(0) to quit the modality of the dialog. when you call destroydialog the post message is not sent. it hangs the system
there is no code for create and destroyDialog methods in the SDK , so i can only guess now
In the following example, posting the message also fails, but if you put it after the messagebox it works.
(
try destroydialog ::ro_test catch()
rollout ro_1 "" width:300 height:300
(
on ro_1 open do
(
windows.postmessage ro_1.hwnd 0x0010 0 0
messagebox "So far so good!"
)
)
here is another problem… and i see it. it seems like the handle open happens too early before the rollout’s dialog told the system about its modality… let me think what we can do
on ro_1 open do
(
windows.processPostedMessages()
WM_CLOSE = 0x0010
windows.postmessage ro_1.hwnd WM_CLOSE 0 0
messagebox "So far so good!"
)
this might work…
No luck. Tried several messages with the same result.
Will have to stick to do all the stuff before opening the rollout, for now.
Thank you Denis, this might be useful for others facing the same problem.
sorry … i just don’t have time to really breakpoint the issue… maybe later. but as i said it’s an interesting challenge
Dont worry about it, it’s not so important. Thankfully I have a workaround and I don’t need to re-write much code at this point.