On Mar 14, 2012, at 03:10 , bassrelig...@free.fr wrote: > I also want the NSWindow to remain the key window so it still receive key > events
This is the heart of the problem. By making your panel's table view *look* active, you're making a promise to your users that keystrokes work in the table view (e.g. up and down arrows and other navigation key in particular). But you *break* the promise if the panel isn't really key. If the panel and its table view are basically just functioning as a kind of pop-up menu, and the table isn't going to respond to keystrokes because the main window gets them somehow, I think a better solution would be to change the panel's table's delegate to prevent *all* row selection in the table. Then, clicking or double-clicking on a row could apply (or insert or whatever) that item to the main window. If you need to choose multiple items from the panel, try using a custom-image-borderless-toggle-button column (a normal checkbox would have the same appearance problem as the table view) instead of selecting rows, along with an "Apply" button. With that approach the issue of the selection appearance of the table view is moot. You could also study the UI behavior of the HUD popup window that you get in IB when you right-click on (say) First Responder. I'm not sure I'd necessarily use IB as a model for any normal app UI, but it might give you some ideas. _______________________________________________ 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
