I tried a different syntax:
--[SCRIPT]
tell application "TextEdit"
activate
set cod to count of documents
make new document
repeat
if (count of documents) > cod then exit repeat
end repeat
set TEname to get name of document 1
tell application "System Events" to tell process "TextEdit" to tell menu bar 1 to tell menu bar item 5 to tell menu 1 to tell menu item 1 to tell menu 1 to set flag to enabled of menu item 2
if flag is false then tell application "System Events" to tell process "TextEdit" to tell menu bar 1 to tell menu bar item 5 to tell menu 1 to click menu item 4 (* switch from Text to Rich Text (RTF) *)
tell application "System Events" to tell process "TextEdit" to tell menu bar 1 to tell menu bar item 5 to tell menu 1 to set name2 to name of menu item 4
end tell -- TextEdit
set the clipboard to (flag as text) & return & name2
--[/SCRIPT]
but got the same behavior: perfect on my machine, wrong on the asker's one.
Maybe one of you looking them with fresh eyes would understand what is wrong.
The 'not really funny thing' is that if I test the wording of the menu item 4, it behaves well on both machines but the test is an awful one because it requires the knowledge of every localized versions.
On an English system the menu item may be “Make Plain Text” or “Make Rich Text”
On a French system it would be "Convertir au format Texte" or "Convertir au format RTF"
On a Portuguese System it would be "Fazer Texto Normal" or "Fazer Texto com Estylo"
I didn't know all the localized versions.
So, this message is not only a request for help, it's also an open letter to Chris NEBEL.
At this time, System Events returns two identical strings for a menu item,
--one named "Title"
and
-- an other one named "Name".
Both are the localized version.
Is it possible to change the System Events behavior so that it returns the localized string as "Name" and the English keyString as "Title".
This would be a clean workaround for this kind of problem:
a menu item changing with the context and the English keystrings unavailable from AppleScript (it's hidden in a xx.nib file).
Don't respond: rely upon the application's preferences.
They may be changed during the working session but the "in ram image" is not reflected in the Preferences file.
Yvan KOENIG (from FRANCE lundi 25 mai 2009 19:04:54)