On 16-Aug-06, at 8:12 PM, Frank Condello wrote:
On 16-Aug-06, at 7:47 PM, Seth Willits wrote:
On Aug 16, 2006, at 4:42 PM, Frank Condello wrote:
The more I look at this the more I think the only way it can work
is if RS does two things:
1. Allow KeyboardShortcut to be changed for QuitMenuItem and
PrefsMenuItem (this may be a legitimate bug already).
2. Add HideMenuItem and HideOthersMenuItem subclasses - maybe
even ShowAllMenuItem for completeness.
I know what I'm trying to do goes against the almighty HIG but
there are good reasons for needing this functionality - games and
kiosks, come immediately to mind.
I'll write up a report later tonight...
And why can't they change it so you can intercept keystrokes
before they reach the menu items? Seems pretty logical to me.
Especially considering other APIs (Cocoa) do this.
True enough - I might try catching kHICommandQuit and
kHICommandHide events with declares, but I'm not sure I can get at
them before the RB framework does (if it does).
OK, here's the feature request: <http://realsoftware.com/feedback/
viewreport.php?reportid=qdczalzt>
For the record, it *is* possible to trap kHICommandQuit,
kHICommandHide (etc.) events and stop'em from going through to the
framework. This at least gives me an option to disable Quit and Hide
reliably in fullscreen mode, but it's kinda nasty in windowed mode
since the menus still look like they're working but they don't
actually do anything. For now it's fullscreen or bust for this
preference - better than nothing I guess...
Frank.
<http://developer.chaoticbox.com/>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
