I'm wondering if there is a Pega best practice on getting a PerformClick method to execute successfully.
I have an automation that doesn't always recognize my PerformClick method the first time. Right now, I have implemented a loop to continuously perform the click until it executes successfully, but I feel that is probably not the most efficient way of configuring my automation.
Any suggestions would be much appreciated. Thank you!
Make sure the controls you are clicking are ready to accept a click. Is the button on a webpage? If so, waitForCreate on the page before attempting to do a PerformClick.
When something works sometimes and other times does not, the issue is usually timing. Timing is usually best resolved with waiting on the correct control. Pauses instead of waits create timing issues and should not be used under most circumstances.
I realize this is an old response, but I'm hoping you can clarify something around your response in terms of development best practices.
You mention using waitForCreate on the page before attempting to click a button, but say timing issues are usually best resolved with waiting for the correct control (assuming the button).
If you are having trouble clicking a button on a webpage ((i.e. having to click multiple times) assuming the waitForCreate for the button has returned true)), would it be suggested to use a waitForCreate on the page as well?
Here's what I think about this. I believe that its scenario/requirement based.
If we have a webpage with large number of controls that we intend to use (e.g. Search page, enter multiple search parameters and click Search button), having a WaitForCreate on Webpage right at the start might be a good idea, given that we have the Control children match rule added and configured appropriately (all the necessary controls checked). This will ensure that all our target controls are matched as a prerequisite for the Webpage to be matched, and having WaitForCreate on Webpage alone might help, as we might not require a separate WaitForCreate for each control that we would interact with. Downside of this approach might be the case that the Webpage might take too long to match depending on the no. of controls that must be matched as well as the network speed that might impact the speed at which page is rendered/created. WaitForCreate Timeout value would need to be tweaked accordingly.
Alternatively, if we do not have the requirement/scenario as mentioned above, having the WaitForCreate on specific controls is always a good idea. If the number of controls that we would be interacting with is small, then having control-specific WaitForCreate blocks might not make the automation too long.
Having WaitForCreate for both, i.e. Page as well as control, is a slight overkill in my opinion unless of course if there is a specific requirement that justifies it.