Perform actions asynchronously on controls.
I have recently posted a question on infragistics forum. Please follow the link below for more details.
To summarize this, we have controls like Combo box, checkbox, ultragrid(cells having other controls like checkboxes and combo boxes etc). When ever user performs an action on the control (like check/uncheck, change selection in combo box), a prompt is displayed to the user for confirming his selection. When running through QTP, performing these actions with the current APIs, QTP execution gets blocked after displaying the prompt. Execution continues only after closing the prompt.
Due to this behavior, we are not able to automate most of our manual test cases.
My idea is to provide a way to perform the actions asynchronously on the controls without blocking the UI thread.
As mentioned in the earlier comment by Michael Germann, we will not be able to implement this across the board, we need to know which specific actions you might require to be done asynchronously.
Michael Germann commented
Unfortunately to do this for all actions would not be feasible, and for some actions it is impossible. That being said if you can list the specific actions and the controls on them that are causing you issues we can see if we can resolve them individually, either to adjust them to work asynchronously and\or give you a viable asynchronous workaround.
To explain why, is how our actions are designed. We primarily follow the design pattern that Mercury, the original creator of QTP, set forth in that we try to have meaningful actions that may combine several UI interactions. While this offers a more readable script, then Click X,Y , Type "***", etc, this has the drawback that any one of those individual interactions that are bundled into one action, in theory could trigger a dialog or other UI stopping behavior that you would need another action to resolve.
Almost every action, especially those with parameters that need to be validated, needs to have some internal steps that are synchronous, this is so if the validation fails, the error message could bubble back up to UFT. Also there are often some setup UI steps, that need to be completed before the primary UI step can be done, each of those generally speaking needs to be done synchronously as well.
That being said, we have over the last few years have been converting a number of our actions if possible to asynchronous calls, as well as the many of the actions on our new controls have been done that way as well. We are doing this by doing as by having just the primary event triggering aspect of the action be asynchronous, which I believe is what you are looking for.
Again we’ve been generally addressing the actions on a case by case basis, if there are specific actions for a control proxy that you are using that you need asynchronously we will see if we can either switch it over or offer a valid work around.
Richard Etherington commented
Did you ever resolve this issue?