'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
<[email protected] <mailto:[email protected]>>
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
--
_______________________________________________
lazarus mailing list
[email protected]
https://lists.lazarus-ide.org/listinfo/lazarus
