[Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)

[David Jenkins]

'Override run' doesn't necessarily mean replace all of it. Inherited can 
be called from the override.  And I'd agree with the addendum "(This a 
critical and complex task, however, that you should only attempt with 
good reason.)".

I looked at the assembly for NSApplication.run, there are a lot of 
things being called and set before the call to nextEventMatching...   
The .isRunning variable being one of them - which is read only and can't 
be set.  It can be overridden (and is one of the suggested overrides) 
but unfortunately there are times, in other parts of the code, that they 
look directly at the ._running variable where the value of .isRunning is 
stored instead of calling .isRunning (look at 
NSApplication._setMainWindow).  Which sets up a mismatch between what an 
overridden .isRunning method would return and what ._running is set to.

Obviously the overrides have worked fine so far.  And I agree with 
Tobias that it is code changes in the 10.15 beta that has really caused 
this to not work.  Setting up NSFrontmostDocumentWindowObserver is new 
to 10.15 and that is where the fault has happened.  It is beta software 
and bugs will be there.  Or functionality that will be removed before 
release. Nevertheless I'd suggest a couple of cautionary points with 
regards to overriding run:

1) I have found Apple Documentation to be overly sparse at points and 
that it doesn't keep up well with new code.  So reading that it you can 
override .run in the Documentation doesn't immediately suggest to me 
that it is a good idea or should be done.

2) Take the "(This a critical and complex task, however, that you should 
only attempt with good reason.)" seriously and call inherited or look at 
inherited (lldb/assembly) and try to implement most of what happens 
there.  Notice that the initial override of run did cause a bug in 
Lazarus that had to be resolved by overriding .isRunning.

I'm fine with a more elegant way to call aloop.  The advantage of what 
we have done is that it is the very first thing that happens when 
NSApplication.run calls nextEventMatching - no if ands or buts.  I had 
originally kicked it off by calling postEvent(event, Yes) (put event at 
top of queue).  This does not guarantee that nothing else happens before 
we get aloop running.  It would be nice to not have the to check 'isrun' 
each time through nextEventMatching.

David




On 6/10/19 6:56 PM, Dmitry Boyarintsev via lazarus wrote:
> On Mon, Jun 10, 2019 at 6:18 PM David Jenkins via lazarus 
> <lazarus at lists.lazarus-ide.org <mailto:lazarus at lists.lazarus-ide.org>> 
> wrote:
>
>     In now.  Mantis 35702
>
> While the research seems to be quite thorough, the following statement:
> "Error is caused because Cocoa currently doesn't run through base 
> level NSApplication.run and thus appropriate ._isrunning flag is not 
> set "
>
> contradicts Apple's documentation 
> (https://developer.apple.com/documentation/appkit/nsapplication?language=objc)
>
> "...Methods to Override
> ...
> Override run if you want the app to manage the main event loop 
> differently than it does by default. (This a critical and complex 
> task, however, that you should only attempt with good reason.)"
>
> If the first statement is true, then run cannot and should not be 
> overriden at all.
>
> thanks,
> Dmitry
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190611/4cde693b/attachment.html>