Check if menu item is available

Hello fellow MacScripters,

I’m trying to improve my Keyboard Maestro Markdown Library at the moment.

One thing that bothered me for a while now is the way how I handle “if Cut is enabled then obviously something is selected therefore something else should happen than if no text was selected”. Right now this works quite well for people using English as their system language. I am looking for a way to improve this for other international Mac users.

Does anyone have an idea how I can check if Cut is enabled or if some text is selected that I haven’t thought of?

Thanks,
Andreas

Hi.

Assuming the keyboard shortcut’s Command-“x” in all cases ” and that GUI Scripting’s enabled, of course ” this should work on recent systems:

tell application "System Events"
	tell (first application process whose frontmost is true) -- Or a named, frontmost process.
		set CutEnabled to (enabled of first menu item of menu 1 of menu bar item 4 of menu bar 1 whose value of attribute "AXMenuItemCmdChar" is "X" and value of attribute "AXMenuItemCmdModifiers" is 0)
	end tell
end tell

Lovely! That solves the problem for a lot of folks! I assume suppose that ⌘X is not the shortcut for cutting in some languages though. I’ll keep investigating in that part. In the meanwhile I’ll adopt your solution and see how well that goes. Thanks.

If someone has an even more generalized idea, I’d love to hear it!

Browser: Safari 537.31
Operating System: Mac OS X (10.8)

Why? A menu item’s title is an localized string. The menu item itself is an allocated object with an short key binded to it. In other words the title and short key aren’t related directly.

Hello.

Some keys gets translated, though they are independent of the menu text. I can’t come to think of any at the moment. But for instance, in Norwegian, you do close the dialog boxes with command-I and not command-D I noticed this first in MS-Word I think, but it pertains to others as well.

Now, why couldn’t they keep this at the same standard as cut copy and delete, which are universal?

That is a mystery to me

Localization,
of common operations,
only leads to confusion,
that is my conclusion.

Hello all

It seems that Zett misunderstood something.
When we test if the menu item is available, the test upon the value « X » doesn’t check a shortcut, it checks a flag which is fully different.
Some shortcuts may be localization depependant when the US « default » one is not available on a local keyboard.
In practice I don’t remember encountering this problem with Apple applications.
Alas, I encountered the opposite : shortcuts which we can’t use due to local keyboard.

I may agree with macUsr about the fact that sometimes localizing item may bring confusion but the law is the law.
In France, applications MUST be localized to be allowed to be sold here.

I wish to add that some odd shortcuts aren’t necessarily linked to localization problems but to historical ones.

For instance, File > Duplicate in some Apple applications has the shortcut cmd + shift + S because it is supposed to be a substitute to Save As. (which is now reachable thru cmd + option + shift + S.

Yvan KOENIG (VALLAURIS, France) mercredi 20 février 2013 14:49:39

Hello.

If the keys lack, or if the key is difficult to type on a keyboard, then that is perfectly good reasons for choosing something else. But then it should be the standard for all apps localized for that language, and not just one or two.

There is no law forcing developers to apply your rule.
Existing standards defined by ISO for instance (look at UTC in Wikipedia) aren’t applied by everybody so don’t guess that developers will play games with same rules.

Yvan KOENIG (VALLAURIS, France) mercredi 20 février 2013 15:02:29

Well. There are at least certain rules that applies to submitters of apps to the Appstore. I think only one or two sentences would do. :slight_smile:

Yes, I saw the flag, but I thought checking the flag is still not localization independent. Please correct me if I’m wrong.

And if I’m wrong that would be perfect!

The reason may be ergonomic. We Germans use almost the same keyboard layout as US. The only obvious difference is that Y and Z are changed. For some weird reason they chose to keep the undo shortcut at ⌘Z instead of mapping it to the same key position (Y), rather than its letter. So every time someone wants to undo here, they have to reach to the middle of their keyboards.

Some countries may have just decided they want to keep key positions for ergonomical reasons.

Some countries may not even have X in their alphabet. There’s a multitude of reasons really. It’s just something programmers have to keep in mind. Time calculations are no fun either.

Almost. don’t forget the umlauts, the braces/brackets and
¢ the german key between left ⇧ and Y (< >) which is missing on the US keyboard
¢ the US key above ↩ ( \ |) which is missing on the german keyboard.

In AppleScript you’re right (as well as numeric calculations depending on the current locale).
But in Objective-C it’s very easy and reliable using the appropriate API

I know about the Z, having been forced to use German layout for odd reasons. A lot of stuff have been mapped due to its placement.

I think it is really all up to Apple to make a norm for their key-bindings for the individual countries, and programmers to adhere to them.

If you find date calculations in C/C++ difficult, then at least ICU can help you on your way if you aren’t lucky enough to program in Objective-C- :expressionless: I have come to loathe freeing pointers, and finding memory leaks in C!

Edit
There is actually this saa/cua standard (Systems Application Architecture/Common User Access) that was this great thing, that all operating systems was more or less to adhere to in the beginning of the Nineties.

This seems to have floated out a little, as for Apple Applications for instance, it seems to be, kind of voluntarily if you want to implement ctrl-F4 to cycle through windows for instance. (Personally I think all apps should acquiesce to this.) But I think there should be one such standard, that all User Interfaces should adhere to, as it would lead to a whole lot less confusion. Also when it comes to any national peculiarites.

I was wrong.

The code was testing the availability of a shortcut.


tell application "System Events"
	tell (first application process whose frontmost is true) -- Or a named, frontmost process.
		tell menu 1 of menu bar item 4 of menu bar 1
			set nbMenuItem to count every menu item
			set liste to {}
			repeat with i from 1 to nbMenuItem
				set mName to get name of menu item i
				try
					mName
				on error
					set mName to missing value
				end try
				set mAttr to get value of attribute "AXMenuItemCmdChar" of menu item i
				try
					mAttr
				on error
					set mAttr to missing value
				end try
				set end of liste to {mName, mAttr}
			end repeat
		end tell
	end tell
end tell
liste
--> {{"Annuler", "Z"}, {"Rétablir", "Z"}, {missing value, missing value}, {"Couper", "X"}, {"Copier", "C"}, {"Coller", "V"}, {"Coller et appliquer le style actuel", "V"}, {"Coller une référence", "V"}, {"Supprimer", missing value}, {"Tout sélectionner", "A"}, {missing value, missing value}, {"Copier le style", "C"}, {"Coller le style", "V"}, {missing value, missing value}, {"Compléter", missing value}, {missing value, missing value}, {"Rechercher", missing value}, {"Orthographe", missing value}, {"Parole", missing value}, {missing value, missing value}, {"Démarrer Dictée", missing value}, {"Caractères spéciaux.", "T"}}

Yvan KOENIG (VALLAURIS, France) mercredi 20 février 2013 17:17:11

You are too naive or too optimistic (maybe both).

They are a lot of « rules » defined for instance in « Mac OS X Human Interface Guidelines » which are violated by third party developer and alas by Apple developers too.

If you are curious like me, under 10.8.2, open the System Preference « Desktop and Energy Saver » and close it.
Open Disk Utility and select the Partition tab and quit the app.
After that, open the Console and search for the word « deprecated » and you will see how Apple apply its own rules.
So, why third party developers would apply them ?
As you are using AppleScript, you will also see deprecated calls which were already flagged in 10.7.

Yvan KOENIG (VALLAURIS, France) mercredi 20 février 2013 17:29:10

Sorry for digging this old thread out, but I’m just about to work on the release of Markdown for Keyboard Maestro 2. This used to work, but now I’m on Mavericks beta 3 and it doesn’t anymore. I tested this with a virtual Mountain Lion and it still works there. Does anyone know how to make this work again? Accessibility for AppleScript Editor and System Events need to be ticked on in the privacy settings.

Here’s the script, just in case.

tell application "System Events"
	tell (first application process whose frontmost is true) -- Or a named, frontmost process.
		set CutEnabled to (enabled of first menu item of menu 1 of menu bar item 4 of menu bar 1 whose value of attribute "AXMenuItemCmdChar" is "X" and value of attribute "AXMenuItemCmdModifiers" is 0)
	end tell
end tell

I’m puzzled by Mavericks behavior.
I tested with Safari but it behave the same in other applications.
menu item 2 of menu 4 is cmd + shift + Z
its attribute “AXMenuItemCmdModifiers” is true (10.8.4 → 1)

menu item 4 of menu 4 is cmd + X
its attribute “AXMenuItemCmdModifiers” is false (10.8.4 → 0)

menu item 5 of menu 4 is cmd + C
its attribute “AXMenuItemCmdModifiers” is false (10.8.4 → 0)

menu item 6 of menu 4 is cmd + V
its attribute “AXMenuItemCmdModifiers” is false (10.8.4 → 0)

menu item 7 of menu 4 is cmd +option + shift + V
its attribute “AXMenuItemCmdModifiers” is true (10.8.4 → 3)

I don’t know if it’s a new feature or if it’s a bug.

Alas, since 2013/06/11 I am unable to enter the SEEDs area (Apple is aware of that) so I can’t report oddities.

I hope that somebody here will be able to file a report about this new behavior to get the truth about it.

Yvan KOENIG (VALLAURIS, France) samedi 20 juillet 2013 14:27:33

I’m back under 10.8.4. and added the vlues returned in this system.
As you may see, the new behavior is annoying because it’s not so precise than the old one.

Thanks, Yvan, very helpful. I did not know about the odd behavior you mention. I’m a bit farther though with my problem.

The script errors on this line:

tell application "System Events"
	tell (first application process whose frontmost is true)
		tell menu 1 of menu bar item 4 of menu bar 1
			set cutEnabled to (first menu item whose value of attribute "AXMenuItemCmdChar" is "X")
			-- Invalid index
		end tell
	end tell
end tell

Although the following:

tell application "System Events"
	tell (first application process whose frontmost is true)
		tell menu 1 of menu bar item 4 of menu bar 1
			get properties of attribute "AXMenuItemCmdChar" of menu item 4
		end tell
	end tell
end tell

returns:

--{value:"X", class:attribute, settable:false, name:"AXMenuItemCmdChar"}

I will restart Mavericks because I just checked the values returned, not the behavior with the used syntax.

KOENIG Yvan (VALLAURIS, France) samedi 20 juillet 2013 15:18:15

Hello

Some things are really bad.
I tested with TextEdit so I was able to run the script with nothing selected : menu item inactive
or with something selected : menu item active
(1) the whose filter is no longer usable. We must use something like that :


tell application "System Events"
	set theProcess to (first application process whose frontmost is true)
	
	set theProcess to process "TextEdit"
	tell theProcess
		tell menu 1 of menu bar item 4 of menu bar 1
			#set cutEnabled to (properties of (get first menu item whose value of attribute "AXMenuItemCmdChar" is "X"))
			-- Invalid index
			set theValues to value of attribute "AXMenuItemCmdChar" of every menu item
			set {maybe, cutenabled} to {0, false}
			repeat with i from 1 to count theValues
				if item i of theValues is "X" then
					set maybe to i
					exit repeat
				end if
			end repeat
			if maybe = 0 then
				# no item whose shortcut letter is X in the menu
			else
				# test the value of attribute "AXMenuItemCmdModifiers"
				tell menu item maybe
					properties of every attribute
					set cutenabled to value of attribute "AXMenuItemCmdModifiers" is in {1, true}
				end tell
			end if
			
		end tell
	end tell	
end tell

In both cases the properties of the attributes of menu item Cut were the same :

{
{value:“AXMenuItem”, class:attribute, settable:false, name:“AXRole”},
{value:“commande de menu”, class:attribute, settable:false, name:“AXRoleDescription”},
{value:menu “Édition” of menu bar item “Édition” of menu bar 1 of application process “TextEdit” of application “System Events”, class:attribute, settable:false, name:“AXParent”},
{value:false, class:attribute, settable:false, name:“AXEnabled”},
{value:{0, 54}, class:attribute, settable:false, name:“AXPosition”},
{value:{298, 19}, class:attribute, settable:false, name:“AXSize”},
{value:“Couper”, class:attribute, settable:false, name:“AXTitle”},
{value:missing value, class:attribute, settable:false, name:“AXHelp”},
{value:false, class:attribute, settable:true, name:“AXSelected”},
{value:“X”, class:attribute, settable:false, name:“AXMenuItemCmdChar”},
{value:missing value, class:attribute, settable:false, name:“AXMenuItemCmdVirtualKey”},
{value:missing value, class:attribute, settable:false, name:“AXMenuItemCmdGlyph”},
{value:false, class:attribute, settable:false, name:“AXMenuItemCmdModifiers”},
{value:missing value, class:attribute, settable:false, name:“AXMenuItemMarkChar”},
{value:missing value, class:attribute, settable:false, name:“AXMenuItemPrimaryUIElement”}}

For sure filing a bug report is needed but as I wrote I am unable to do that since 2013/06/11

Worse, as I wrote here about Mavericks, maybe Apple will ban me from SEEDs :roll eyes:

Yvan KOENIG (VALLAURIS, France) samedi 20 juillet 2013 15:56:59