<div dir="ltr"><div dir="ltr">On Tue, Jun 11, 2019 at 10:43 AM Zoë Peterson via lazarus <<a href="mailto:lazarus@lists.lazarus-ide.org">lazarus@lists.lazarus-ide.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">David did the research on this one, but IMHO, this is a bad idea.  As he <br>
said, the inherited run does more than just set _running before it <br>
starts calling nextEventMatchingMask; </blockquote><div>Yet Apple suggests that "run" method can be overridden.</div><div>That's very true, that Apple can add much more into "run" method and it would be nice if we could use the code.</div><div>Yes, overriding "run" has its own risk of not being future compatible. </div><div>But I don't recall any flawless macOS update. On each new macOS version there were some "LCL incompatible" changes anyway.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">that's is just the bit that causes an obvious crash.  It's also poking around the implementation rather <br>
than relying on the public API, so it will be more likely to break again going forward.<br></blockquote><div>Public API is actually refers to methods, not instance names.</div><div>Actually instance variable name are specifically should be named with underscore in them </div><div>(<a href="https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/KeyValueCoding/Compliant.html">https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/KeyValueCoding/Compliant.html</a>)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If it's a problem to check isRunning every time through <br>
nextEventMatchingMask, and alternative with the same behavior would be <br>
to swizzle in the runloop variant before calling inherited run and <br>
switching it back once we get into it.<br></blockquote><div>Switching back? how is it possible? <br></div><div><br></div><div>I don't really like the idea of hijacking the event loop for quite a simple reason.</div><div>The nextEventMatchingMask can be called for whatever event, and hijacking can violate the conditions of the call.</div><div>(for example, if the method is called with a timeout, and LCL hijacks the loop. Then it never returns withing specified time).</div><div><br></div><div>We cannot be sure at what particular event, the hijacking would occur.</div><div>Today, there was a bug report, about crash in the hijacking approach</div><div><a href="https://forum.lazarus.freepascal.org/index.php/topic,44930.msg323420.html#msg323420">https://forum.lazarus.freepascal.org/index.php/topic,44930.msg323420.html#msg323420</a>  <br></div><div>The application written caused nextEventMatchMask to be called even prior to Application.Init.<br></div><div>So eventually the method is as risky as overriding "run", and not a good design.</div><div><br></div><div>(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)</div><div><br></div><div>thanks,<br>Dmitry</div></div></div>