Sleep Function Problem

[water]

I'm sure there is a wait-until-the new-screen-is-displayed function available. So you only send keys  when the new screen is available. 

Please check the Programmer's Guide. 

[AzgarD]

4 minutes ago, water said:

I'm sure there is a wait-until-the new-screen-is-displayed function available. So you only send keys  when the new screen is available. 

Please check the Programmer's Guide. 

Thats the problem, i can't wait the screen changes, i have to send all the KeyStrokes one after another

[water]

8 hours ago, AzgarD said:

Thats the problem, i can't wait the screen changes, i have to send all the KeyStrokes one after another

That's what I don't understand.
Host applications are screen related. You enter data into the screen and then press a key sending the screen content to the host. When the host has processed the data it returns a new screen or updates the current screen.
So I see no need to press keys over and over while the host is processing your Input.

[AzgarD]

7 hours ago, water said:

That's what I don't understand.
Host applications are screen related. You enter data into the screen and then press a key sending the screen content to the host. When the host has processed the data it returns a new screen or updates the current screen.
So I see no need to press keys over and over while the host is processing your Input.

The need for press the keys as soon as possible is sales related. If the keys are not send while the screen is "frozen", my company lose the sale, and then you can imagine what this mean to the financial situation of the company. Anyway, i'll try some stuff. Thanks for the help

[water]

I assume that the key presses we are talking about go to the host window.
So what I described above is still true. When you send (P)F4 function "INST" is triggered. How do you notice that the "freeze" (means: processing) after (P)F4 has ended and the host session is ready for the next key press/data entry?
Lets say the title of the host window changes. So I would send the (P)F4 key to the host and then wait until the screen title has changed. Then send the next command. This way your script executes as fast as possible without filling up the command queue which will be processed when the current (P)F4 key has been executed. Processing this queue with multiple key presses leads to unexpected results.

Send a key -> wait for a result showing the key has been processed -> send the next key ....

[AzgarD]

3 hours ago, water said:

I assume that the key presses we are talking about go to the host window.
So what I described above is still true. When you send (P)F4 function "INST" is triggered. How do you notice that the "freeze" (means: processing) after (P)F4 has ended and the host session is ready for the next key press/data entry?

I know that because if we do this manually or using the AutoIt the keys continue to being sended to the follow screens. That's a fact.
 

Quote

Lets say the title of the host window changes. So I would send the (P)F4 key to the host and then wait until the screen title has changed. Then send the next command. This way your script executes as fast as possible without filling up the command queue which will be processed when the current (P)F4 key has been executed. Processing this queue with multiple key presses leads to unexpected results.

If you mean the window name, that not happens. All the way of the process the name of the window still the same.

As i sayed, for the process can be right the keys have to be "pressed" regarless of the screen. The AutoIt did that in the most nice way could be, bu the problem was the "F4" spam, because of the delay of the double clicking.

Edited August 24, 2017 by AzgarD