Keyboard Problem

[kylepyro]

I've distributed a one line task (A) as an exe that runs another task (B) continuously. Task A simulates a folder trigger which can't be distrbuted and B does the actual work.

The combination of these two task seem to be interferring with the keyboard and user can't type information correctly. If they press caps lock it will type normally for a few characters and then "unpress" itself. I can recreate this condition on my own machine where AA is installed.

What I'm observing is that I can press caps lock and get caps for a few letters and then the kb reverts to caps lock not being depressed regardless of the physical state of the key. This produces strings like this - KKkkkk. There is no change in the physical state of the key.

This condition occurs both inside the prompt windows of my task and inside applications like notepad while task A is running. I observe similar behavior with the shift key as well. The condition clears immediately whenever I end the task or kill the exe's. I can recreate this running both the exe's and running the tasks natively inside AA itself.

Each iteration of task b contains a 500ms delay regardless of whether their is any work to perform or not. Task B automates a routine clerical function done many times a day so I'm trying to eliminate having to load the exe every time its needed.

Any ideas?

[forumsupport]

Hello,

If you wish to enter your text in uppercase always then use Shift keys like this,

Keystrokes: [SHIFT DOWN]abcd[SHIFT UP][ENTER] in "Untitled - Notepad"

It will enter abcd in uppercase always regardless of CAPS LOCK status on keyboard.

If it does not help, please upload your task so that we can look into it.

You can locate your task by selecting your task from Task List, right clicking that particular task and selecting 'Locate on disk' from context menu. Otherwise, you can also send text format of task. For that, open your task in a Task Editor, go to Tools->Save as text file and send this text file.

It would help us investigate further.

[kylepyro]

I understand the proper function of caps lock and shift. I am not trying to manipulate those keys in my script. I'm saying that the exe files created by AA are interfering with the proper function of those keys.

I've attached task a and b as well as a csv in zip form that is used by task b so you can see what going on. Task A is InsuranceDriver. Task B is Insurance Cert Rename.

I conducted two experiments after my post. 1st I lengthed the delay at the bottom of task b to 3000 ms from 500 ms and you could see the caps lock remained locked longer, but it still unlocked itself. 2nd, on my own machine I set up a folder trigger that fires the task b atmn script. Under this configuration, the keyboard functions normally, so there is something about the run task command in task a that is driving this problem.

[kylepyro]

So, if anyone is reading this I did eventually figure this out. Whenever an AA EXE runs it appears to "restore" the keyboard to the original state when the script was first recorded. (Something to keep in mind if your planning to use keystrokes in a script.) This process was using a two step method to emulate a trigger and the inner EXE was resetting the keyboard state, thus unlocking the caps lock whenever it restarted.

The solution was to re-engineer the emulation of the trigger to something inside the internal exe and abandon the external exe altogether. Simple enough once you figure out what its doing.