On Apr 20, 2016, at 12:08 PM, Ray wrote: > Peter - many thanks for your thoughts here! I believe the answer is to just > manually include the " ...ctrl+A" in the menu item. The limitation with > this solution is I can't 'right justify' the keyboard shortcut part of the > menu item. Thus, other menu items which have sub menus show the right > pointing arrow much farther to the right. I guess I could duplicate the > contextual menu in a fixed menu bar but I like to avoid redundancy. > > I'm actually popping up the contextual menu as a right-click choice on a data > grid. It changes depending which column in the grid you right-click. Does > that sound like bad interface to you?
I often use a popup this way, to provide contextual choices to the user. What I don't get about what you're trying to do is this: if the user does a <ctrl-A>, what is supposed to happen? Given that just typing ctrl-A doesn't give the "audio" command (whatever that does) any context to work from? And if the audio command doesn't need a context, then why put it into a contextual popup in the first place? I guess I don't understand what your aim is. > On 4/20/2016 11:55 AM, Peter M. Brigham wrote: > >> On Apr 20, 2016, at 11:35 AM, Richard Gaskin wrote: >> >>> Ray wrote: >>> >>>> I'm unable to popup a button as a contextual menu and show keyboard >>>> shortcuts. For example, I'd like users to see "Audio ctrl+A", not >>>> just "Audio". >>>> >>>> The button's style is "menu" and the button's contents for that line >>>> is "Audio/A". The "Audio ctrl+A" displays fine as long as the >>>> button's "menuMode" is pulldown, but as soon as I use the popup >>>> command to pop the button up contextually, it's menuMode is changed >>>> to "popUp". This loses the display of the keyboard shortcut. I now >>>> only see "Audio" instead of the desired "Audio ctrl+A". >>>> >>>> Does anyone know how to keep keyboard shortcuts while using the popup >>>> command? >>> I don't believe the OS APIs support that. The HIGs for all supported >>> desktop platforms suggest using context menus as a secondary convenience >>> for items also available in the more visible menu bar. >>> >>> Given that design mandate, it seems the assumption is that users can learn >>> shortcuts when viewing the menu item in their primary location, regardless >>> whether a subset of those items is also available in a more ephemeral >>> secondary form such as a context menu. >>> >>> On an implementation level, following the design mandate certainly makes >>> things easier for the developer, as both LiveCode and the OS support >>> keyboard triggers for visible menu items such as those in the menu bar, but >>> since a popup only exists at the moment it's popped up there's no way to >>> hook the event from the object. >> >> Usually popup menus are really contextual menus anyway, and give the user >> choices that are quite dependent on the control being clicked on. They can >> be (and I think usually are) constructed on the fly, to allow for, eg, >> actions specific to a field, or even to the text chunk clicked on. Whereas >> keyboard shortcuts (and the menu choices associated with them) are generally >> more global in scope. If you really need to have shortcuts listed in a popup >> menu, you could construct them yourself on the fly -- on mousedown; put >> "Audio ctrl+A" into btn "myPopup"; popup btn "myPopup". I don't know when >> this would be actually useful, but then I don't know what you're trying to >> do here. -- Peter Peter M. Brigham pmb...@gmail.com _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
