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

Dmitry Boyarintsev skalogryz.lists at gmail.com
Wed Jun 12 07:02:39 CEST 2019

Btw, I'd prefer to keep COCOALOOPOVERRIDE define in the source code.
As neither approach is 100% clean, we'll pretty much want to have an option
to switch between one another.

The cleanest way however - is to modify LCL itself!
So there would be no need to call a "runloop" procedure (thus no need to
either hijack the event loop and/or override run)
Obviously, on the condition that the widgetset CAN handle Pascal exceptions
in LCL friendly manner.


On Wed, Jun 12, 2019 at 12:56 AM Dmitry Boyarintsev <
skalogryz.lists at gmail.com> wrote:

> 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/b9b95e1c/attachment-0001.html>

More information about the lazarus mailing list