Windows 7 - 64 bit, "Send" not registering in window after it is Activated, I am converting XP 32 bit scripts

[YoungPadawan]

Hello,

First off thank you for taking a look at my probably very simple problem to you. I have searched this forum, the help files, and googled about a million variations of my issue.

Having said that, I am an amatuer programmer, my script is not pretty, and I have clipped my script down to the bare bones below.

I would like to press a key in a window, however, I built my scripts in XP 32 bit and now run Win7 64 bit. They do run, can be paused, but only outside the window I want to press a key in!

It does succesfully bring the window I want to use to the top, but again it fails to "Send" any key in that window.

Also, the script can not be "Paused or Unpaused" while in that window. Nor will it let me terminate with the "ESC"

Please help me figure this out, It is driving me crazy LOL.

---------------------------------------------

WinActivate("XYZ")

Global $Paused

HotKeySet("{PAUSE}", "TogglePause")

HotKeySet("{ESC}", "Terminate")

$i=0

;;;;; Auto Click Program ;;;;;

Do

Sleep(300)

Send("=")

Until $i=1

;;;;; Close Program Block ;;;;;

Func TogglePause()

$Paused = NOT $Paused

While $Paused

sleep(100)

ToolTip('Script is "Script PAUSED : Paused"',0,0)

WEnd

ToolTip("")

EndFunc

Func Terminate()

Exit 0

EndFunc

Edited January 2, 2012 by YoungPadawan

[MilesAhead]

I'm not sure exactly what you are trying to do. But I'll make a few observations. When you do HotKeySet() get the return value and see if the function succeeded. If it returns 0 that takes the mystery out of waiting for stuff to happen that never will. Using Esc as a hotkey is generally a bad idea. Most applications that have any edit capability or even pop up an error dialog expect the dialog or window to close when Esc is pressed. You're interfering with a standardized key to no good effect.

Never hurts to sprinkle some MsgBox statements around when debugging.

[YoungPadawan]

MilesAhead,

Thank you for your reply:

In regards to the purpose of the script, I have truncated the Do block a lot from the real block, in order to simply identify "how" I should modify a "Send" function or, if needed, some other portion of the program to allow the output of that function to be recognized by the Activated window.

The send, in this case, is set as a spam output to simply provide me feed back on the recognition of the key press (i.e. it would cause a repetitive chime in the program in this case due to invalid input). I could set a MsgBox, but that would not tell me if the window itself recognized the key input, it would only tell me that a MsgBox could be displayed over the top of it. That does not solve my mystery unfortunately.

The Pause and Esc selection, while not elegant for many applications, works very well for this one. As when the script is asked to terminate it is generally time to end the program as well and when asked to pause it interferes with nothing in the current configuration. As indicated, that part is quite functional, just not inside the window that was activated. I can move to the task bar, mouse select it, and pause or terminate at will. I just can't do that while in the activated window. And that is what I need to be able to do. Start and stop, while resident inside the application and while sending the output of the Send functions and other Do block commands in the intervening time to that window.

Additionally, the 4 users that asked me to fix this have also asked me to change to this key from some other selections as they use almost all other normal keys already for something else and the ESC key is situated out of the way and is generally not accidentally pressed. The program itself has a tendency to crash and not to generate any error dialog boxes if a problem occurs, a .log is created to address that.

I have hypothesized that perhaps changing the permissions or the relationship of the programs to each other might be the answer but have no idea how or if that is the rght path?

Edited January 2, 2012 by YoungPadawan

[YoungPadawan]

To ensure that the output was indeed being sent I adjusted the Do block as such below.

The MsgBox did indeed create and overlay the activated window. Again, not what I would like to do but it does confirm that the script itself is pushing output and cycling to get to the MsgBox after going through the Send/ControlSend.

Additionally, I tried ControlSend to specify the window itself. No discernable output was registered inside the program.

*** It seems to not be a problem with the output, but rather with the Activated window allowing input. ***

I am new to Win7 and as said before am converting these scripts from XP. Is there is something that I should do to allow the windows to accept input in this way? That is most likely the problem.

Do

Sleep(300)

ControlSend("XYZ", "", "", "=")

MsgBox(0, "Feedback", "=")

Until $i=1

[YoungPadawan]

I love it when persistence pays off.

The solution:

#requireadmin

It was the UAC, it wouldn't say anything, it just prevented input.

Send works fine, pause and ESC do to. It works exactly the same as the XP flavor. With one more line of code to get past the UAC. And I don't have to disable the UAC either. A win-win.

Thanks for the views, I will mark it solved now.

[MilesAhead]

I keep forgetting about UAC. First thing I do after installing Vista or later is disable it. Still don't know what you're trying to do but it's trivial to get a handle to the active window. Then you can send it messages, move it to foreground etc. when needed. It doesn't have to have the input focus all the time. During Send of course, but not always. Also look at some of the WinAPI UDF libraries you can download. They make it easy to use WinAPI calls that can do quite a bit of stuff on Windows. Most stuff you need can be done with canned code afa windows showing/hiding/placement/closing/effects etc..

[kylomas]

YoungPadawan,

What was kicking UAC? The script that you posted does'nt look like it should need elevated authority.

kylomas

[kylomas]

YoungPadawan,

Based on the title of your post I believe that the UAC prompt was kicked when you executed _sqlite_startup(). The function then downloaded the DLL and wrote it to a "program" folder which caused you to need the #requireadmin.

IF this is true then you can remove the #requireadmin and this and all subsequent calls to the startup function will work.

@jchd - Does this sound right to you?

kylomas

[jchd]

Probably correct. One more reason why I don't like the automated download feature for fetching the DLL.