Thanks Jacque. Yes, there was no perceptible performance hit by processing all menus so all OK there.
I agree that the shortcut keys should be enabled/disabled in parallel with their associated Edit menu items but I'm not seeing that behavior. Here's what I did on a card with just one editable field. I haven't written any code to handle the command key shortcuts. - made sure the cursor was in the field and the field was empty - clicked the edit menu, everything was disabled - typed some data into the field - checked the Edit menu again - all still disabled - selected some text in the field and pressed command-C to copy - moved the cursor to a different place in the field and pressed command-V - the copied text was pasted into the field This was in the IDE (with my application's menu bar enabled), LC 5.0, OS X 10.6.8. I haven't tried it in a standalone yet Am I missing something? Pete lcSQL Software <http://www.lcsql.com> On Sun, May 13, 2012 at 6:53 PM, J. Landman Gay <jac...@hyperactivesw.com>wrote: > On 5/13/12 4:39 PM, Peter Haworth wrote: > > I discovered then that there's a problem with those group mouseDown >> handlers on a Mac - it's impossible to tell which menu was clicked because >> "target" and "me" both return the name of the menu group, not the menu >> that >> was clicked, so you end up adjusting menus when they don't need adjusting. >> To complicate matters more, on Windows, the target does return the menu >> button name. >> > > I just set everything. It's fast enough. I have one mousedown menu handler > that adjusts twenty or more items and it's fine. You could try it and see > how it goes. > > Menu buttons on OS X don't receive messages, which is why you aren't > getting the info you want, and why the mousedown handler has to be in the > group. > > > If an Edit menu item is disabled, does it's Mac command key and Windows >> shortcut key equivalent still work? If not, that would be an issue with >> this approach unless I watch for those keys as well as using a mouseDown >> handler. >> > > If a menu item is disabled, so is its command key. That seems reasonable > to me. The command keys are just shortcuts to the menu items and should > behave the same. You can work around it with a commandKeyDown handler in > the card or stack. That will always fire, but it can interfere with the > real menu shortcuts sometimes. > > Another way to handle it is to re-enable menu items the user might need at > the end of a menupick handler. If the menus aren't pulled down, no one can > tell if the items are enabled or not and their command keys will always > work. > > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.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<http://lists.runrev.com/mailman/listinfo/use-livecode> > _______________________________________________ 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
