WaitForKeyEx ( ... ) bug

[archimede]

Hallo.
I explain you a WaitForKeyEx ( ... ) bug, that exists ONLY on the compiled version ( yes there is a different behaviour on the interpreted version and in the compiled version ).
I maintein ENTER  pressed.
If I use
WaitForKeyEx ( {ENTER}, 1 )
that detect the ENTER click; if I maintein ENTER pressed the next command
WaitForKeyEx ( {ENTER}, 1 )
NO DETECT ENTER pressed.
To now I avoided it with this command immediately BEFORE WaitForKeyEx ( ... ):
SendKey ( "{CLEAR}" )

Regards
Archimede

[kdmoyers]

Can you please post a very small program that shows the problem?
Maybe a program less than 10 lines long?
That will help us understand.

[archimede]

Hallo.
This is a script test I made for you.
The problem shows only in the compiled version (WHY?) and only sometime (WHY?), not everytime.
you must call the program at he command line level; when launched you must press F12 and mainein it pressed: when leave again the button the program shows a message: this is right.
Sometime the compiled version shows the message after you pressed F12, because it no detect it is presses too...

[archimede]

Hallo.
In the test script I tried to change the time delay from 0.5 to 1 second, then I tested the compiled version: it no generates error.
But in my bigger program it generate error too... :-(

[td]

Your problem very likely has nothing to do with a "bug" except the bug in the way you compile or start your script. The only differences between a compiled and interpreted script are the script's compiler manifest settings and the location the script starts from. Otherwise, it is exactly the same function being executed by exactly the same interpreter.

[archimede]

:-)
I no see any particular option to compile: can you tell me what are the compilation option I can change?
I made a script; I compiled the script; I launched the script on the first screen, the compiled on the secon screen: the 2 version works in 2 different mode ( like I explained you before ).

[td]

Manifests:
https://docs.winbatch.com/mergedProjects/WinBatch/Manifests.htm

Manifest settings for compiled scripts:
https://docs.winbatch.com/mergedProjects/WinBatch/WINBATCH_S__005.htm

[archimede]

:-)
Thank you very much.
I saw it... it seeem no important for the problem I explained before.
Can you tell me what are the right settings to solve the problem?
:-)

[td]

Why do you think UAC (manifest settings) are not important?  Manifests control how a process interacts with other processes and the OS. That is exactly what WaitForKeyEx is doing.  We can't tell you if manifest settings will fix your problem or which ones you need to use. It all depends on your system's configuration and the type of account you are executing the script in. You will need to trial and error that for yourself. The topic is discussed many times on this forum and in articles in the Tech Database if you need more background.

[archimede]

I see no many options and that seems to have a different meanings.
If is like you tell the limit is on the WaitForKeyEx (...) documentation that no tell anything about this problem (or this limit).

[td]

UAC isn't specific to any one function. It is part of the operation system and can apply to many different WinBatch functions. You need to develop an understanding of UAC and manifest settings and not just focus on the documentation of one function if you are going to script in the modern Window environment. If you apply a little logic to the problem based on the existing UAC documentation links, you should be able to sort it out.

[edit]  You also need to consider all aspects of the context difference between a script that works and one that doesn't work as you think it should. For example, what are the functional differences between your working compiled script and non-working compiled script? What type of account is each script running under? If you mimic the UAC settings of the WinBatch exe in your compiled script does the script then work?  Do you think you might have more than one application running on your system that is checking key states when the application does not have the input focus? There are many more things to consider so don't limit yourself to one thing in your thinking.