Question
Atos
IN
Last activity: 7 Dec 2020 8:55 EST
WaitForInputAllowed made the bot slow
Hi,
We were facing issues in prod environment with mainframes application where as there were no issues in non prod.
To fis this issue, I have used WaitForInputAllowed on mainframes screen before sending key strokes. And that made tha bot very slow.
Can anyone suggest any better idea or what made it slow
Cognizant Technology Solutions
GB
Hi Tejaswini,
As per my understanding the WaitForInputAllowed method, will wait for a certain amount of time(30000 ms). This will ensure that the controls get created.
Instead, you use the IsCreated property of an object to see if it is matched at a specific point in time. Along with this you define a looping logic, that will check if the control is created, if it is created it will proceed, if not it will take the else path and retry again.
We faced exactly same issue, and the use of isCreated saved us. Hope this helps.
Thanks
Pegasystems Inc.
US
It would help to see a screenshot of your automation. Generally speaking, the way I prefer to navigate between text adapter screens is to use the NewScreenShowing event. I wait for this event and use the "Setup" of the WaitForEvent to trigger the keystroke that changes the screen. The WaitForInputAllowed is really used only for scenarios where you have a screen that is basically blocked until something else happens. In my experience, this isn't very common.
You'll know when you need the WaitForInputAllowed based on automation errors telling you the field is not editable or something to that effect.
Atos
IN
Hi Thomos,
I cannot share the screenshot of the code.
what i observed is NewScreenShowing event is at Adpater level not at screen level. And the 2 text adapters will be created even before the automation starts. So i did not use this event.
Errors are as screen not created and mainly not consistant. And only in prod envt not in non prod.
WaitForInputAllowed resolved those errors but bot became very slow
Pegasystems Inc.
US
It doesn't sound like you are waiting for the right event to navigate between screens then. I would suggest writing the NewScreenShowing event to a ListBox on screen so you can see when it happens. You can then navigate manually and that would tell you if you can wait for it or not. I don't follow your explanation of why you cannot use it, but if you can test it for yourself, I am betting you'll see enough information to determine where it would be appropriate. Its usage is in places where you might navigate from Screen A to Screen A (back to itself) as there's no other event you can really wait for in that case.