Hi,
I am using the popup watcher class to handle some debug windows that are non-blocking but come up randomly. Its not something which is under my control.
However what I am noticing is that, when the secondary thread clicks on 1 message it leads to multiple iterative messages. In the middle of this, meanwhile the main thread has clicked on my access point within the AUT which expectedly does not work since the debug dialogs are still active.
How should I be handling this?
My Program.cs for handling the popups below
class Program
{
public static SomeRepository repo = SomeRepository.Instance;
[STAThread]
public static int Main(string[] args)
{
// Uncomment the following 2 lines if you want to automate Windows apps
// by starting the test executable directly
//if (Util.IsRestartRequiredForWinAppAccess)
// return Util.RestartWithUiAccess();
Keyboard.AbortKey = System.Windows.Forms.Keys.Pause;
int error = 0;
PopupWatcher alertDialogWatcher = new PopupWatcher();
alertDialogWatcher.Watch(repo.Alert, CloseAlertDialog);
alertDialogWatcher.Start();
try
{
error = TestSuiteRunner.Run(typeof(Program), Environment.CommandLine);
}
catch (Exception e)
{
Report.Error("Unexpected exception occurred: " + e.ToString());
error = -1;
}
return error;
}
public static void CloseAlertDialog(Ranorex.Core.Repository.RepoItemInfo myRepoElement, Ranorex.Core.Element myElement) {
repo.Alert.ButtonNo.Click();
}
}
Pause main thread when Popup watcher thread is working
-
- Posts: 2
- Joined: Wed Jan 22, 2014 1:29 am
Re: Pause main thread when Popup watcher thread is working
Hi avinashp22,
Unfortunately it is not possible till now to reach the main-thread out of the PopupWatcher-thread. Maybe the “multiple iterative messages” are not created if you close your popup instead of clicking the close-button?
As a workaround, please try to implement following code:
Regards,
Robert
Unfortunately it is not possible till now to reach the main-thread out of the PopupWatcher-thread. Maybe the “multiple iterative messages” are not created if you close your popup instead of clicking the close-button?
As a workaround, please try to implement following code:
Code: Select all
myPopupWatcher1.Watch(@"RxPath/to/form-object", CloseAlertDialog);
Code: Select all
public static void CloseAlertDialog(Ranorex.Core.RxPath myPath, Ranorex.Core.Element myElement)
{
//Close Popup
Form f = (Form) myElement;
f.Close();
}
Robert
Re: Pause main thread when Popup watcher thread is working
Hello.
OP, have you figured out a fix to this? I am being plagued by the exact same issue.
Thank you,
Wes
OP, have you figured out a fix to this? I am being plagued by the exact same issue.
Thank you,
Wes
Re: Pause main thread when Popup watcher thread is working
This is a symptom of the design of the threading model that Ranorex uses in the PopupWatcher class. There is no "cross-talk" between the main thread and the watcher thread. The main thread can talk to the watcher, but not the other way around.
One thing to note is that once the PopupWatcher finds the element it is watching for, it will take control of the mouse/keyboard, as needed, until it finishes it's work. It will then hand them back to the main thread. This should not be counted on as a 'pause' though, as it might take a small amount of time for the watcher to recognize the element, allowing the main process to try to continue. To help with this, you can put delays in your tests in the locations where the dialog might popup up. This will give the watcher a chance to grab the mouse/keyboard and do it's work before the main thread attempts to continue. Remember, Ranorex will go as fast as it possibly can, so you always have to be mindful of unintended side-effects.
If you truly want your tests to pause when you are handling a dialog, then you probably need to create an actual test module to handle that dialog, and put it in your test suite in the spot(s) where you expect the dialog might appear. You can use an if-statement in user-code to decide whether the module should be executed or not.
The PopupWatcher class is intended for handling truly random dialogs such as network errors, etc., that do not need to be waited on.
In my experience, when someone has wanted to use the popup watcher in the way described in the original post, they are usually better off handling the dialog using test modules and 'if' logic instead of the PopupWatcher.
One thing to note is that once the PopupWatcher finds the element it is watching for, it will take control of the mouse/keyboard, as needed, until it finishes it's work. It will then hand them back to the main thread. This should not be counted on as a 'pause' though, as it might take a small amount of time for the watcher to recognize the element, allowing the main process to try to continue. To help with this, you can put delays in your tests in the locations where the dialog might popup up. This will give the watcher a chance to grab the mouse/keyboard and do it's work before the main thread attempts to continue. Remember, Ranorex will go as fast as it possibly can, so you always have to be mindful of unintended side-effects.
If you truly want your tests to pause when you are handling a dialog, then you probably need to create an actual test module to handle that dialog, and put it in your test suite in the spot(s) where you expect the dialog might appear. You can use an if-statement in user-code to decide whether the module should be executed or not.
The PopupWatcher class is intended for handling truly random dialogs such as network errors, etc., that do not need to be waited on.
In my experience, when someone has wanted to use the popup watcher in the way described in the original post, they are usually better off handling the dialog using test modules and 'if' logic instead of the PopupWatcher.
Shortcuts usually aren't...