> On Oct 18, 2022, at 9:43 AM, Dragan Milić via Cocoa-dev > <cocoa-dev@lists.apple.com> wrote: > > Hi all, > > I’m developing a tiny application, which has an NSStatusItem instance with a > menu. One for the menu items of the menu has a custom view, which is either > an NSTextField instance, or in can even be an NSView instance containing the > NSTextField instance (the latter approach enables me to add some borders > around the text field). However, I have problems setting focus on that text > field. Clicking the text field does nothing and if I click on it repeatedly a > couple of times, the application hangs (and eventually crashes), getting into > the infinite loop of -[NSMenuWindowManagerWindow setFirstResponder:] > messages, even stealing keyboard events from all other applications while > hanging! > > In essence, I can’t set focus on the text field nor type anything into it. I > had this problem on older versions of macOS (Catalina and older), but after > clicking on the text field a couple of times, it would get the focus > eventually. On Big Sur and later, it’s not possible, and clicking on the text > field repeatedly hangs and crashes the application. > > This issue isn’t related to the menu being attached to the NSStatusItem, it > also happens in the main and/or contextual menu within the application. I’d > eventually want to set the focus on the text field programmatically each time > the menu appears (so a user can start typing immediately, something like > Spotlight used to do in the older versions of macOS), but that’s not possible > either. > > The only similar attempt I could find is dated back in 2008 on this very > list, you can find it here: > > https://lists.apple.com/archives/cocoa-dev/2008/Jan/msg00138.html > > But even at that time, the problem was hard to solve. > > I know NSMenu has its own track of the event loop and I assume that’s what > causes the problem. Action-On-Click oriented controls (NSButton, > NSPopUpButton…) work fine embedded in an NSMenuItem instance, but not > NSTextField. I wonder if what I want to achieve is even possible. If so, I’d > really appreciate if someone can offer the solution or point me in the right > direction for further investigation and solution attempts.
I can tell you that the Help menu does itself use makeFirstResponder: on the text view, although in some brief experimentation, even if I comment out that call from the Help menu code, AppKit will still find the text view as the best candidate for key focus when the menu window is ordered onscreen, and sets the window’s first responder to the key view automatically. (This behavior may only happen automatically on macOS 11 and later, though, due to changes in the menu window implementation; not sure about earlier macOS versions. It wouldn’t surprise me if the explicit call to makeFirstResponder: was required on earlier versions.) The Help menu code uses some Carbon code to check for the kEventMenuOpening event on the Help menu and performs makeFirstResponder: at that point. I would expect menuWillOpen: to be received at about the same time as that Carbon event, so would also be a reasonable time to call makeFirstResponder:. I might be able to help find the issue with your code if you can provide me with a sample app (buildable from source). -eric _______________________________________________ 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
