Set value of text field

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

Thanks for help in advance.
Best,
Kalman

Can you post a screenshot of the Window in question, with the text field you are trying to edit hilighted?

Have you tried coercing that number to text? I don’t know if that will help, but it’s the next thing I would try.

Try

tell text field 2 of group 1 of splitter group 1 of window 1
set selected to true
delay 0.1
keystroke “1.3”
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

Thanks all your helps
Best Kalman

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 field without 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).

1 Like