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
