Help with script - Copy clipboard content into custom field in Project Settings

Hi everyone!

I need some help with perfecting a script. I used Nora’s script as a starting point. My script works… sometimes. There are some problems with the sleep delays, as my computer can be slow to open the project settings, but that I can adjust.

What happens often is that the CTRL + V step is sent too soon/late (not quite sure), so I can see the script play out, but nothing is copied into the custom field. 

I tried using super long sleep times to see if it was just a matter of speed, but it didn’t seem to prevent the problem.

Any idea? Maybe using Clipboard commands instead of the ctrl + v one? I’m an (enthusiastic) ahk beginner so I’m not yet familiar with the Clipboard commands! 

Here’s a Screenshot of the custom field and my current script:



Trados Studio Project Settings window with a custom field open for text entry, but no text is pasted into the field.


^+t::
Send ^+p ;custom Studio Shortcut to open the Project settings
Sleep 999
Send Proj
Sleep 999
Send Lang
Sleep 999
Send All
Sleep 999
Send TR
Sleep 999
Send U
Sleep 999
Send {Tab 2}
Sleep 999
Send {F2}
Sleep 999
Send ^v
Sleep 999
Send {F2}
Sleep 999
Send {Enter}

When in the Project screen with a project selected, the hotkey should open Project settings, navigate to the Update screen, open the custom field and copy the content of the clipboard, then close the text box and move selection to the OK button without clicking it, allowing me to double check the copied text before clicking ok.

Thanks in advance! 



Generated Image Alt-Text
[edited by: Trados AI at 4:24 AM (GMT 0) on 5 Mar 2024]
emoji
Parents
  • Hi ,

    I use Dragon commands, not AHK, but something weird happened when I updated to Studio 2019.

    As usual, some of my Dragon commands stopped working when I updated to Studio 2019.

    Strangely enough, it turned out that Studio was suddenly ignoring, for example, an "Enter" key sent by a Dragon command when an "Enter" key sent by the keyboard still worked. Or Studio was suddenly ignoring an "Alt-m" key combination sent by Dragon that still worked when sent manually with the keyboard.

    I am not saying that this is what is happening in your case, but just that it is something to keep in mind as a possibility if Studio seems to be ignoring AHK key sequences that work fine when entered manually using the keyboard

    I still don't know exactly what was happening. As far as I can tell, the dialog boxes were not losing focus, as I was able to find a workaround using other key sequences -- which I don't think would have worked if the focus had switched to another window.

    Good luck with your macro :-)

    Studio's user interface is non-standard and old, so I guess we should just be happy that it works as well as it does most of the time.

  • Hi again

    I thought I should also mention how I discovered the problem I described in my previous post.

    For the "Alt-m" key combination, for example, pressing that key combination on the keyboard moved the cursor to an entry field and highlighted the contents, which could then be replaced with something else.

    After trying everything else, I finally inserted a "MsgBox" command after the "Alt-m" key combination to stop the Dragon command and see what was happening.

    I found that the cursor had not been moved into the field and the contents were not highlighted. But if I then used the keyboard to manually press "Alt-m", the cursor moved into the field.

    It did not matter how long I waited in the Dragon command, the "Alt-m" key combination simply did not work any longer when used in the Dragon command. But if the command was stopped at that point, then "Alt-m" worked when the keyboard was used. And the "Alt-m" still worked fine if the entire sequence of keystrokes was manually entered.

    The same thing happened in another Dragon command that pressed the "Enter" key. Studio simply stopped recognizing the "Enter" key from the Dragon command, but if I stopped the command at that point, then pressing "Enter" on the keyboard still worked and if the entire sequence was manually entered using the keyboard the "Enter" key still worked.

    Very strange. But luckily I was eventually able to find workarounds in all of the cases.

    I am looking forward to SDL upgrading to an up-to-date user interface, but I wouldn't hold my breath waiting.

  • Thanks for  all the info! I used Dragon too but didn’t seem to run into that kind of problem.

    You seem to have really described that is happening - anything done manually works, continuing the script manually if it stops at any step works fine - It just won’t work consistently when automated!

Reply Children
  • Hi

    I tried alternate ways of using the keyboard, then checked them in my Dragon commands until I found something that worked.

    In the case where Alt-m suddenly stopped moving the focus to an entry field, I eventually found that a simple right arrow key would also move the focus to the field. I then tried changing the Alt-m to a right arrow key in the Dragon command and found that it worked reliably.

    I don't remember what I did when an Enter button stopped responding to an Enter key sent by the Dragon command, but it was essentially the same thing. I found an alternate way to use the keyboard to activate the button, tried it in the Dragon command and found that it worked.

    Of course, the nasty thing is that parts of the decades-old Studio user interface now appear to depart so much from Windows standards that you can no longer assume that if it works using the keyboard in Windows then it will also work using AutoHotKey or other keyboard simulators.

    I was definitely not expecting that when I was debugging my Dragon commands.

    So, when writing a Dragon command, I now also have to keep in mind the possibility that the command might not work even if it has been written correctly. That makes life with Studio a bit more complicated.

    Let's hope the situation doesn't deteriorate further.