Weird behavior for modal stacks and answer dialogs

[Bob Sneidar]

In more recent versions of MacOS the ability to interact with an application that was not the foreground application was added as a feature. For instance I can scroll a web page using the mouse wheel even though the web browser is not the frontmost app. I'm not sure how this could be disabled for modal windows only. 

I have seen other apps that do NOT allow interaction with a window if it is in the background. Perhaps what we need is a new command to turn off background interaction?

Bob S


> On Sep 9, 2019, at 04:30 , Paul Dupuis via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> On 9/9/2019 6:50 AM, Giovanni via use-livecode wrote:
>> Hi everybody,
>> I’m writing here to report a very strange behavior of modal stacks and answer dialogs on MacOS Yosemite and Sierra.
>> Basically the modal windows or dialogs, in these OSes simply does not work and this seems to happen since LC 6.7.x!
>> When you open a modal stack the expected behavior is that the script execution is interrupted and you cannot interact with the calling or other opened windows. While the first thing seems to happen, the second one doesn’t work: you can click on buttons, fields or any other control in the calling stack or any other stack opened.
>> I think that this is a very big problem mainly in porting applications from older versions of LC to the newest one and it’s quite strange that nobody else noticed this before or consider this a problem.
>> 
>> I already filed a bug report at https://quality.livecode.com/show_bug.cgi?id=22368 <https://quality.livecode.com/show_bug.cgi?id=22368> in which you can also find a demo stack to easily reproduce the behavior.
>> 
>> Anyone can comment on this? Are you experiencing this as a problem? Is there a workaround or a solution for this?
>> 
>> The problem seems not to be present on Mojave but I was not able to try on other versions on MacOS and it’s not present on Windows.
>> 
>> 
> 
> This one has been around for a while, and I thought it had been previously reports (but still not fixed). I seem to recall there was a lengthy discussion of it on the list a long time ago.
> 
> The work-around seems to be locking things down before calling an ask or answer dialog (lock messages, lock your menus and so on) so that no other user actions can start any other script.