Sign in to follow this  
Followers 0
bcnx

Script locks up keyboard

6 posts in this topic

#1 ·  Posted (edited)

Hi all,

I have this line as the last one in my script:

Run("dial.exe" & " " & $nummer,"",@SW_HIDE)

If I run this command manually, everything is fine, but if I run this within the produced EXE, about 2 out of 5 times my keyboard is taken hostage by the AutoIT EXE, as if one key (don't know which one) is stuck or as if some keys received different functions. Only solution is to do a ctrl-alt-del and then "escape". That gives me back my keyboard and all to correct key-bindings.

Anyone any idea about this very strange behaviour? I also tried ShellExec, but that give the same results. I use the very last version of AutiIT.

Thx!!

Bart

Edited by bcnx

Share this post


Link to post
Share on other sites



A few suggestions:

1) Add Opt("TrayIconDebug", 1) to your script. Then the next time your script is running and it hijacks your keyboard, you can hover the mouse over the script's systray icon and it will show you exactly what line of code it's actually processing in case it's not the one you're thinking.

2) Download and run Process Explorer from Sysinternals. It's a much-improved version of the Process tab of Task Manager, and will give you a good idea of which process is doing what. Run it before starting your script and then you can see what dial.exe is doing, or to at least kill its process to see if that frees up your script. If you can't get enough info from Process Explorer and you're feeling adventurous, ProcMon from the same site will show you everything that's going on under the hood.

3) "number" has a "b" in it.

Jeemo


An emoticon is worth a dozen words.

Share this post


Link to post
Share on other sites

Hi Jeemo,

Thx for your quick reply!

1) I added the line you mentionned, but the icon disappears very fast again. Probably because dial.exe is a wrapper for another EXE that unload immediately. I'm quite sure that it the last line is the culprit, since I have no problems when removing that line.

2) will do. As mentionned, dial.exe loads dialer.exe and that is the only process remaining. But even when I kill it, the keyboard hijack is still there.

3) nummer is a correct word, however not in English, but in Dutch :-)

Thx,

B.

Share this post


Link to post
Share on other sites

2) will do. As mentionned, dial.exe loads dialer.exe and that is the only process remaining. But even when I kill it, the keyboard hijack is still there.

When you say "kill it", are you talking about dial.exe or dialer.exe? If the latter, then even when you kill dialer.exe the keyboard is still locked up?

I'm a bit confused - your first post says that the AutoIT script locks up your keyboard, but then in your last post you said that the system tray icon comes and goes in an instant. That suggests to me that while the keys are locked up, the script has already been terminated. If that's the case, then your script probably isn't directly responsible (although it might instantiate something that is responsible).

I guess the best way to clarify is if you can tell me which of the following processes are running while the keys are locked:

YourScript.exe

Dial.exe

Dialer.exe

Then, after doing your "escape" sequence, does the list of running processes change?

3) nummer is a correct word, however not in English, but in Dutch :-)

Ohhhh, you Dutch and your silly ways. muttley

An emoticon is worth a dozen words.

Share this post


Link to post
Share on other sites

When you say "kill it", are you talking about dial.exe or dialer.exe? If the latter, then even when you kill dialer.exe the keyboard is still locked up?

dialer.exe.

dial.exe disappears by itself after being launched (being a wrapper for dialer.exe).

I'm a bit confused - your first post says that the AutoIT script locks up your keyboard, but then in your last post you said that the system tray icon comes and goes in an instant. That suggests to me that while the keys are locked up, the script has already been terminated. If that's the case, then your script probably isn't directly responsible (although it might instantiate something that is responsible).

I concur. My guess is as well that the scripts instantiates in some way the problem. Best proof is that, by running the command manually, there is no problem whatsoever. So it seems that by wrapping the command in the AutoIT script, things go wrong. I tried to launch the command in different ways (for instance by launching it via a command shell), but no luck.

I guess the best way to clarify is if you can tell me which of the following processes are running while the keys are locked:

YourScript.exe

Dial.exe

Dialer.exe

Then, after doing your "escape" sequence, does the list of running processes change?

Only dialer.exe is running. I did a save of the process list before and after and no apparent difference. I'm going to test now with antivirus software disabled.

Ohhhh, you Dutch and your silly ways. muttley

Err, Belgain actually ;-)

Thx again!

B.

Share this post


Link to post
Share on other sites

Hi,

I finally decided to give AutoHotKey a try to tackle this. Similar tool, somilar syntax, but for some reason the keyboard hijack does not take place.

O ell, All's well that ends well ...

Bart

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0