Because, according to @peternlewis, the KM pop-up is dynamically generated, and is NOT available until the pop-up button is clicked. So it make NOT be available to the accessibility commands like pop.entireContents(). The properties of the "pop" object may be set BEFORE the .click().
Whereas the TextEdit font pop-up is a static menu, always available.
You can try selecting the KM popup item by position using keycode down arrow or by name by keystroke of the first characters of its name. But I don't really know that will work. It's trial and error.
Here you're suggesting that you can get the menu items via System Events (although perhaps you didn't mean to).
While this is a statement I'm inviting you to confirm or deny.
Okay. Let's find a pop-up button that has a dynamically generated menu – like the Finder's Get-Info window's Open-With button.
We are able to get UI elements from it after it has been opened, and discovering that we can get the menu items in menu 1:
--------------------------------------------------------------------------------
# Requires a file to be selected in the Finder and its Get-Info window to be open.
--------------------------------------------------------------------------------
tell application "System Events"
tell application process "Finder"
set frontmost to true
tell (first window whose subrole is "AXStandardWindow")
tell pop up button 1 of scroll area 1
click
delay 1.5
tell menu 1
name of UI elements
end tell
end tell
end tell
end tell
end tell
--------------------------------------------------------------------------------
Now then – the History button in the Keyboard Maestro editor would seem to be of type button rather than type pop up button.
Is there a difference in type button that prevents Accessibility from seeing the menu once its open?
No, I'm talking about accessibility. Not what System Events can do, what someone using say VoiceOver can do.
What you get out of System Events is whatever it gives you.
I'll try to have a look to see if it can be made visible to System Events, but it's not particularly a priority I'm afraid - better would be time spent on improving actual AppleScript access.
