Re: UI scripting...
Re: UI scripting...
- Subject: Re: UI scripting...
- From: David Gregg <email@hidden>
- Date: Mon, 11 Jan 2016 01:44:13 -0700
> On Jan 11, 2016, at 12:52 AM, Jean-Christophe Helary <email@hidden> wrote:
>
> Thank you David for checking.
>
>> 2016/01/11 15:35、David Gregg <email@hidden> のメール：
>>
>>> On Jan 10, 2016, at 5:40 PM, Jean-Christophe Helary <email@hidden> wrote:
>>>
>>> Well, I tried to select the application as indicated in the manual but it never appeared in Target. It may be because I installed UI Browser a little while ago without using it (I remember deleting it a few weeks ago) and the 30 days being over I don't have access to that part. But I do have access to the Screen Reader.
>>
>> I am able to set the app as a Target in UI Browser.
>> However, you can't access that text field, only its parents which include the combo box.
>
> Can you clarify what you mean by "you can't access the text field" ?
> In UIElementInspector I can access it fine.
Sorry, what I meant is that you can not access the text field through UI Browser.
>
>> If you assume that the search field is the first active element on that window when it opens, then you can use a simple keystroke command to enter the search criteria. I believe that is a good assumption although it needs further checking.
>
> The assumption is correct. I can insert a string with keystroke. But that works only for keys I can access directly and won't work with a complex string. Japanese won't work for ex. O I guess I'd need to simulate all the keystrokes to produce the output which would not not be practical if I were to set the search string value automatically.
You can also simulate key codes through System Events. You might be able to automate the determination of the key code for each letter. Then you would just loop through the character key codes for search field entry. Obviously more work than just entering a word between quotes.
>
>> I prefer to use repeat loops instead of delays whenever possible, delay is unreliable in the later versions of OS X.
>
> I just put that here because it looks like there is a delay between the moment the window is created and the moment it is recognized by AS. Do you suggest that I use a dummy repeat look that lasts the amount of time I need ?
No, what I have provided is the equivalent of an event notification. It waits until that object arrives on screen. This automatically adjusts for differing computer speeds and/or loading.
>
>> If there are keyboard shortcuts available I generally prefer to use them over menu item commands as they are less dependent on language and menu bar structure.
>
> OmegaT has full shortcut configuration so that would be risky. But right now I am just exploring what I can do with UI scripting, not really putting things in stone. Besides for the fact that UI scripting would be used only until better data exposure is implemented. What I am trying to do here is explore how I can create an AppleScript library for an application that 100% Java with very little OSX specific code. I'm exploring command line AS wrapers to simplify parameter use when launching the .app application (users who run the .jar version have less issue with the command line) and a number of other things to make some features more discoverable than they are now.
You can use the method you were using. I did notice that there was a slight error in the command.
Instead of:
click menu item 18 of menu 4 of menu bar 1
it should be:
click menu item 18 of menu 1 of menu bar item 4 of menu bar 1
>
>> You could change the name of the window from "Text Search" to suit your language requirements. I used the name/title of the window instead of "1" because the latter would not work with the repeat loop method of delay, although it would work with the tell block.
>
> I want to make the script language independent because I don't know in which language environment it will be used.
Okay...
>
>>
>> Depending on your other needs it looked like most of the other GUI elements were accessible through UI Browser and could be added to the handler if you prefer a more complete workflow.
>>
>> set searchCriteria to "essai"
>> doSearchOmegaT(searchCriteria)
>>
>> on doSearchOmegaT(searchCriteria)
>> tell application "System Events"
>> tell process "OmegaT"
>> set frontmost to "true"
>>
>> repeat until exists menu bar item "OmegaT" of menu bar 1
>> end repeat
>> keystroke "f" using command down -- Search Project… command keyboard shortcut
>> repeat until exists window "Text Search"
>> end repeat
>>
>> tell window "Text Search"
>> keystroke searchCriteria -- assume that search field is first active field on window
>> delay 0.1
>> get value of text field 1 of combo box 1
>> end tell
>>
>> end tell
>> end tell
>> end doSearchOmegaT
>
> That works, but with the caveat that I mention above. I can't simulate *typing* Japanese for example.
>
> Jean-Christophe
>
>>
>>> Would that explain why I can change a text field value with UIElementInspector but not with Script Editor ?
>>
>> Yes...
>>
>>>
>>> Jean-Christophe
>>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> AppleScript-Users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> Archives: http://lists.apple.com/archives/applescript-users
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden