Hi Pros,
I have a small problem. I can’t set data to text field.
I try but no good result.
tell application "System Events" to tell (first application process whose bundle identifier is "com.figure53.QLab.5")
tell pop up button 2 of group 1 of splitter group 1 of window 1
click
delay 0.1
click menu item kurva of menu 1
end tell
tell text field 2 of group 1 of splitter group 1 of window 1
set selected to true
delay 0.1
set value to 1.3
end tell
end tell
Still waiting on a reply from TarrKalman.
Would very much like a screen capture of the window with the fields and buttons he’s trying to script to be hilighted.
Hi Folks,
This is the final working formula I use to set these params. Works good form me.
See my solution snippet.
tell text field 2 of group 1 of splitter group 1 of window 1
try
set focused to true
delay 0.1
set value to 1.3 as text
delay 0.1
keystroke (key code 36) -- required to press "Return" key
end try
end tell
Sorry I wasn’t able to help.
I downloaded Lab 5.x.x, and I could only find a text field 2 of group 1 of splitter group 1 of window 1 if I have a cue selected and in the lower pane I have the “Triggers” button selected. Text field 2 turns out to be the “Velocity” field. No other button has a text field 2. That is why I wanted a screenshot because it was way to ambiguous to be able to help you.
A UI element of the text field class works in a very standard way that is easily manipulated by way of UI scripting, provided that it exists somewhere on the screen and would be able to, in principle, receive focus were the user to manually click inside the field, unless the only reason that would prevent it from obtaining focus is that the element is disabled (a disabled text field appears greyed-out and cannot have its contents edited by the user).
If the conditions above are met, UI scripting allows us to interact with a text fieldwithout requiring it to be either focused or enabled. Thus, the following line from your snippet can be removed:
set focused to true
which is unnecessary and generally not effective for actually assigning focus to an element.
@Krioni hit the nail on the head by noticing the main issue:
coercing was perhaps meant more figuratively, as the underlying point was that a text field’s value property will always return, and should always be supplied, a string (or text) value. Thus the following line:
set value to 1.3 as text
whilst fine, could more appropriately be written as:
set value to "1.3"
A text field is able to perform a set of actions that simulate those that can be performed by a user interacting with it manually. At the very least, this will include the showing of the context menu as would follow a user’s right-click (action "AXShowMenu"), and the termination of editing through confirmation typically signified when a user hits ⤶ (action "AXConfirm").
AXConfirm allows this confirmatory action to be performed without having to worry about focus, nor the need to issue simulate keystrokes (which would, indeed, require focus to be appropriately directed to the text field, providing much scope for things to go awry). Thus, the following line:
keystroke (key code 36) -- required to press "Return" key
would be replaceable with:
perform action "AXConfirm"
None of the delay commands are needed, nor the try enclosure. It’s unclear from your original code whether clicking menu item kurva is required in order to display the text field that is otherwise hidden. As explained initially, a hidden element cannot be accessed through scripting, and if its visibility does depend on clicking menu item kurva belonging to the pop up button, then this presents one of only two points at which a scripting error might arise from premature attempts to access a non-existent element before it physically materialises on-screen. The best (most robust) way to accommodate this eventuality is to create a repeat loop that is predicated upon the non-existence of the element in question in order to maintain the loop, punctuated by a single delay 0.5 command call. Here’s how it could be implemented to accommodate both stress points in your script:
tell application "System Events" to tell (the first process ¬
whose bundle identifier is "com.figure53.QLab.5")
tell group 1 of splitter group 1 of window 1 ¬
to if it exists then
tell pop up button 2 to if it exists then
click it
tell a reference to menu 1's ¬
menu item kurva
repeat until it exists
delay 0.5
end repeat
click it
end tell
end if
tell a reference to text field 2
repeat until it exists
delay 0.5
end repeat
set value to "1.3"
perform action "AXConfirm"
end tell
end if
end tell
If the text field isn’t dependent upon the clicking of menu item kurva, then the second repeat loop isn’t required. However, the above serves to illustrate this technique, which is nonetheless applicable to the pop up button in much the same way. As they currently stand, those repeat loops have the potential to loop ad infinitum, which is generally something one should endeavour to avoid. This could be done by supplying a bailout condition that halts the script after a certain amount of time (e.g. 10 seconds) has passed waiting for an element to appear. This is left as an exercise for you to consider implementing (hint: the delay command is already undertaking the job of monitoring intervals of time).