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

[Dmitry Boyarintsev]

On Tue, Jun 11, 2019 at 10:43 AM Zoë Peterson via lazarus <
lazarus at lists.lazarus-ide.org> wrote:

> David did the research on this one, but IMHO, this is a bad idea.  As he
> said, the inherited run does more than just set _running before it
> starts calling nextEventMatchingMask;

Yet Apple suggests that "run" method can be overridden.
That's very true, that Apple can add much more into "run" method and it
would be nice if we could use the code.
Yes, overriding "run" has its own risk of not being future compatible.
But I don't recall any flawless macOS update. On each new macOS version
there were some "LCL incompatible" changes anyway.


> that's is just the bit that causes an obvious crash.  It's also poking
> around the implementation rather
> than relying on the public API, so it will be more likely to break again
> going forward.
>
Public API is actually refers to methods, not instance names.
Actually instance variable name are specifically should be named with
underscore in them
(
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/KeyValueCoding/Compliant.html
)


> If it's a problem to check isRunning every time through
> nextEventMatchingMask, and alternative with the same behavior would be
> to swizzle in the runloop variant before calling inherited run and
> switching it back once we get into it.
>
Switching back? how is it possible?

I don't really like the idea of hijacking the event loop for quite a simple
reason.
The nextEventMatchingMask can be called for whatever event, and hijacking
can violate the conditions of the call.
(for example, if the method is called with a timeout, and LCL hijacks the
loop. Then it never returns withing specified time).

We cannot be sure at what particular event, the hijacking would occur.
Today, there was a bug report, about crash in the hijacking approach
https://forum.lazarus.freepascal.org/index.php/topic,44930.msg323420.html#msg323420

The application written caused nextEventMatchMask to be called even prior
to Application.Init.
So eventually the method is as risky as overriding "run", and not a good
design.

(for example: NSApplication might send a certain event to NSWindow. Until
the event has been processed it would leave some internal variables
uninitialized as well)

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190612/6424895c/attachment.html>