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. thanks, Dmitry On Wed, Jun 12, 2019 at 12:56 AM Dmitry Boyarintsev < [email protected]> wrote: > On Tue, Jun 11, 2019 at 10:43 AM Zoë Peterson via lazarus < > [email protected]> 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 >
-- _______________________________________________ lazarus mailing list [email protected] https://lists.lazarus-ide.org/listinfo/lazarus
