Actually, I was not aware you could disable system menu items. It may be that LC is greying out the items, but still handling the hot keys. I suppose there ought to be a way to prevent copying content in LC as a security precaution, say for copyrighted material as an example.
Bob On May 14, 2012, at 9:31 AM, Peter Haworth wrote: > 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 _______________________________________________ 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
