Problem with <CTRL><c>

[Catorcio63]

Hello,

after I run an AutoIt (v3.3.14.2 on WIndows 7) script, the "standard/classic" <CTRL><c> shortcut to copy selected text to the clipboard does not work anymore for most applications (<CTRL><x> and <CTRL><v>  continue working); the "copy" item from the context menu continues to work. There is no doubt that this problem happens only after running the AutoIt script. The AutoIt script does nothing weird, it starts some applications, manages their windows, sends some clicks and keystrokes and completes successfully. The AutoIt script runs as admin (#RequireAdmin). To fix the problem requires restarting Windows. Of course, I do not redefine the <CTRL><c> shortcut in the script.

Any idea? Am I the only one to experience that?

Regards.

[JLogan3o13]

@Catorcio63 bring up the on-screen keyboard to see if any keys are stuck down after the running of your script. You can check the Wiki entry for this:

https://www.autoitscript.com/wiki/FAQ#Why_does_the_Ctrl_key_get_stuck_down_after_I_run_my_script.3F

Also, help us help you by posting your script

[weirddave]

So if you run a background task the does some Send()'s and you use the PC to do some typing, if you use the modifier keys (alt, shift, ctrl), they can get stuck? This explains a lot! I can stop hammering the keys now  

[Catorcio63]

I found out!

First, I run my script soon after login, in order to set up the PC to my liking. One of the tasks of the script is to launch TrueCrypt and to send it some clicks. When I was writing the script, I discovered that that was possible only if the script runs as admin (#RequireAdmin), otherwise TrueCrypt does not accept the AutoIt clicks emulation. Then the script launches some programs (Notepad++, Firefox, etc.): for all those program the <CTRL><c> does not work, just because they are run as admin (which is actually unnecessary).

One solution (still to test) I think would be to extract in a separate ancillary script the code that deals with TrueCrypt, which should contain #RequireAdmin, and then to launch that ancillary script from a main script which does not run as admin. Any other idea?

Regards.

[JLogan3o13]

The dual-script method is certainly the option most folks go with in this situation. You could also try this:

 

[Catorcio63]

Another problem to solve.

Consider these two scripts.

Script A

#include <MsgBoxConstants.au3>
RunWait("AutoIt3.exe scriptB.au3")
MsgBox ( $MB_SYSTEMMODAL, "ScriptA.au3", "ScriptA.au3")

Script B

#include <MsgBoxConstants.au3>
#RequireAdmin 
MsgBox ( $MB_SYSTEMMODAL, "ScriptB.au3", "ScriptB.au3")

Script A is intended to run script B and to wait for script B to finish before proceeding.
If you comment out #RequireAdmin in script B, the two scripts work as intended.
While, if #RequireAdmin is executed in script B, then RunWait in script A does not wait . This is likely due to the fact the process running the argument of RunWait, because of the #RequireAdmin instruction, spawns a child process to run as admin and then immediately returns (causing RunWait to complete). Now, can you see an easy way to "wait" on the child process? I mean, one solution could be, in script A, to get the set of "AutoIt" processes just before the execution of RunWait and then just after the execution of RunWait and then make the difference between the two sets, but to me it looks a bit cumbersome and maybe there are a few scenarios in which that would not work. Thanks in advance for clever suggestions!