How do I wait for screen to refresh without using pauses, in mainframe?
Currently, we are automating in the mainframe (QWS3270) using the GenericWinHllapi adapter.
We are using pauses to wait for the screen to refresh and then check the status line for specific texts and then progress to the next steps from there. (See attachment for details).
We currently wait/pause 1 second before checking the status. Is there another method(s), without using pauses, to wait for the screen to refresh, and then grab the change? We tried using the TextChanged WaitForEvent, but that doesn't work (we have submitted a defect ticket against that, already).
One concern was that, what if the mainframe takes 3 seconds to refresh, or 10 seconds, or x number of seconds. So, instead of using explicit waits/pauses, is there another way to do this?
I'd create a function that waits for entryResultRegion to have one of the desired values. I included an example of a function that will check infinitely until the text is matched or there is an error. You might want to add a timer or counter that breaks the loop after a certain amount of time.
Typically, I would do this, however, it is a workaround that the client has said they are wanting to avoid.
Also, it wouldn't work since the same status message from the previous message can also appear after inputting data and submitting it into the mainframe. For example, from account 1, if it was processed successfully, it would show "REQUEST PROCESSED." If I input for account 2, and the status message is "REQUEST PROCESSED," the logic shown above would not recognize that the new account was processed. And if the response took a few seconds, it would be processed as "REQUEST PROCESSED" because the response would come in at a later time, as an error or another status message.
We tried a 1 second wait, and it works fine, however, when the mainframe is bogged down and works slowly, in the afternoon, it processes the statuses incorrectly. We have seen this happening in real time.
We also tried TextChanged WaitForEvent, but it doesn't work, as the text change is not recognized, even when it does change. We have submitted an issue ticket against this, already.
What the client wants, pretty much, is a WaitForScreenRefresh method, where Pega recognizes that the screen has actually refreshed, so if the status message is the same, we are ok to process it.
Is there any text on the screen that is guaranteed to change? You could wait for that text to change using the same function above. Then after that text changed, check the area of the screen where you really want the value.
As stated above, the thing to worry about is what if the previous account was successful and the next one was successful. There would be no difference in text. There is a refresh on the screen that happens really quick, but the text remains the same. This is the problem with checking again if the text has changed.
I would use the WaitForInputAllowed method. This method is for Text Adapters Screen. the WaitForInputAllowed method will wait until the screen is ready for input, up to the timeout interval you specified using this method.
There are actually 3 different operations taking place here:
The response arrives back from the Server. Server and network load can affect this time dramatically.
The Browser digests the response. This is typically what one creates an "OnDOMReady" event to catch. This again can take several seconds.
The only guaranteed-to-work way that I know of is to poll for some value in some field (it could be hidden) which knowledge or experience tells you is the last field to finally render before all settles down. If the only real unknown in the 3 bullets above is the time spent on the server, then some variation of an onDOMReady, followed by a fixed delay (which might be different for each screen), might also serve you well.
WaitForInputAllowed functionality changed in build 8.0.1045. Starting in this version you can simply put in the timeout and the method will wait.
Prior to this version, WaitForInputAllowed would throw an exception if input was not allowed. This required a loop with a try..catch around the WaitForInputAllowed. You would wait until the method did not throw an exception - break the loop on no exception.
The event you really want is NewScreenShowing. Do a wait for event on NewScreenShowing. Execute your keypress from the Setup of the wait for event.
As stated above, you can't loop because if the previous account was successful, and the current one was successful, the status won't change, and thus, the check would be useless. The solution would be to do a wait for a new screen (screen refresh) and then check because even if the same status appears, the new screen would dictate when it is safe to check.