I have my own version of assertion boxes, as most people have.
Sometimes when I pop up a message box like that (using AlertWindow::showYesNoCancelBox) the whole program hangs.
It appears that often, or always, when I pop up one of these from within a Component::paint call there is some sort
of message/event jam and everything grinds to a halt.
Is there a known restriction that you should not open a AlertWindow::showYesNoCancelBox from within a Component::paint?
Is there a way to KNOW that we are inside a Component::paint so that I can skip the AlertWindow all together?
Sorry, but WTF!? That’s like asking “is there a restriction that says I shouldn’t saw-off a branch while I’m sitting on it?”
Seriously, modal loops are horrible things even at the best of times, and you should never use them except when there’s genuinely no alternative. At some point I’ll probably deprecate them. But calling one in a paint() method is just a recipe for disaster!
Indeed. Unfortunately it took time for me to realize I had jassert’s in my path until some odd calls fired them. I still want assertions where they are, and I still want my message boxes.
Is there a way to figure out that the situation is extra messy? Would it make sense to check CHECK_MESSAGE_MANAGER_IS_LOCKED and suppress all modal windows?
A possibly better plan: make your object trigger an async update, opening your desired window sometime soon from within a handleAsyncUpdate implementation.
No. It would make sense to not use any modal windows at all![/quote]
Perhaps, but these are assertions. The program may be fcked up anyway. The program MAY be in a state of sudden death OR it can be ignored safely, and I wish to have a way to click my way through that.
It’s not like these boxes will remain in the release build.
