Pause main thread when Popup watcher thread is working

Class library usage, coding and language questions.
Posts: 2
Joined: Wed Jan 22, 2014 1:29 am

Pause main thread when Popup watcher thread is working

Post by avinashp22 » Wed Jan 22, 2014 1:35 am


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;

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);

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) {

User avatar
Posts: 24
Joined: Tue Dec 17, 2013 6:43 pm

Re: Pause main thread when Popup watcher thread is working

Post by rprehm » Tue Jan 28, 2014 2:50 pm

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:

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;

Posts: 17
Joined: Thu Aug 13, 2015 9:30 pm
Location: Fresno, CA

Re: Pause main thread when Popup watcher thread is working

Post by wcrockett » Fri Jan 15, 2016 6:34 pm


OP, have you figured out a fix to this? I am being plagued by the exact same issue.

Thank you,

Ranorex Guru
Posts: 2683
Joined: Tue Feb 07, 2012 4:14 pm
Location: Austin, Texas, USA

Re: Pause main thread when Popup watcher thread is working

Post by krstcs » Fri Jan 15, 2016 8:05 pm

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.
Shortcuts usually aren't...