LCObjectPost/Send callback issue with answer dialogs

[Janschenkel]

I was being silly when I wrote 'answer ... without messages' as this would lead to much hair-scratching for newer developers - I think it's better to not immediately dispatch messages that aren't specific to the modality chain, and queue them for later delivery. And I specifically use the term modality chain as the desktop platforms allow for document modality besides application modality - using the 'sheet' command or 'as sheet' option for the 'answer' and 'ask' commands.

Jan Schenkel.

[LCMark]

right, what I'm suggesting is the second answer command should behave like it has "wait until answer dialog 1 is done with messages" just before it... rather than cancelling out immediately. I think that would be closer to user expectations.

It should be possible to add a wait before the modal is shown in popupanswerdialog() that ends when the current displayed answer dialog ends - indeed, this could also be done for desktop answer dialogs too although there could be some issues there with nested wait loops and window modality. The result of this would mean that answer dialogs would be displayed in the order that they are requested, with only one ever being displayed at once.

I was being silly when I wrote 'answer ... without messages' as this would lead to much hair-scratching for newer developers - I think it's better to not immediately dispatch messages that aren't specific to the modality chain, and queue them for later delivery. And I specifically use the term modality chain as the desktop platforms allow for document modality besides application modality - using the 'sheet' command or 'as sheet' option for the 'answer' and 'ask' commands.

How do you tell which messages are related to the modality chain, and which are not, and which need to be serviced 'in the background' regardless of modality?

The main problem at the moment is that waits nest on the native code stack - so if one message runs, calls wait, another message dispatches and calls wait then the second wait has to resolve before the first one. This presents a problem, for example, with sheets where you can popup a sheet on two stacks, but the second one has to be dismissed before the code after the first one was displayed is executed...

Eventually we will get to a point where it will be possible to make 'waits' happen side-by-side and independent which would lead to much more 'expected' behavior and solve the sheet issue as well as making 'wait' generally more useful for background blocking behavior (for example, libUrl uses wait, and some of the problems people encounter with it at the moment is due to doing a 'get url' in a message that is sent whilst another 'get url' is being processed).