On Feb 14, 2017, at 3:44 PM, James Walker <jam...@frameforge3d.com> wrote: > > I have a situation where makeKeyAndOrderFront is making a window visible but > not key. Just before this call, [theWindow canBecomeKeyWindow] returns YES, > and just after, [NSApp keyWindow] returns nil. Clicking on the window title > bar does not make it key. However, if I bring some other app to the front > and then bring my app back to the front, the window in question finally does > become key. > > When this problem occurs, [NSApp isActive] returns NO although my app's name > is in the menu bar, and doing [NSApp activateIgnoringOtherApps: YES] does not > rectify the situation. > > This only happens if I have linked against a certain dylib that was built > with FireMonkey, not Xcode. I haven't actually called any functions in said > dylib. Any idea what nefarious things it might be doing?
It might provide categories on Cocoa classes that (inadvertently?) replace existing methods. Alternatively, it might provide classes or categories which implement +load methods or it might use C++ static initializers or C/C++ __attribute__(constructor) functions. Any of those can allow it to run stuff at load time whether you've explicitly called any functions or not. Among the things such code could do is swizzle methods of Cocoa classes, changing their behavior. Regards, Ken _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
