Hi Audrey Demers,

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 Audrey Demers

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!

Hi Audrey Demers

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.

Hi Audrey Demers

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.