Problem is that dialogs I have are really unexpected - first
they pop-up at random step in test script, second
they should not pop-up at all (as I close them at the beginning of test script - where they are expected - with 'Do not show again' check box marked).
The work around you have suggested is really difficult to implement as any call to Ranorex method that affect UI should be updated (enclosed in some kind of if
or replaced with some wrapper). It is not as complicated as needs extensive amount changes in test code. I would suggest implementing a fix in Ranorex libraries which is nearly the same as work around you have suggested:
is implemented in Ranorex libraries - it is possible to implement fix in it for situations when main thread's test code prevents pop-up handler from closing pop-up dialog.
Fix can be implemented in following way:
- - When PopupWatcher detects any pop-up - it sets certain 'global block flag' to true, starts handler of that pop-up in separate thread and adds that thread ID to 'global pop-up handler thread IDs list' (both 'global block flag' and 'global pop-up handler thread IDs list' should not be exposed to users of Ranorex API)
- All Ranorex methods that perform any action with UI (Click, Activate window, Maximize... - all methods that affect UI in any way) - before starting UI-action check 'global block flag' (from previous item) - if flag is set to false - they proceed with action, if flag is set to true they do not perform action and start to wait for flag to become false and meanwhile perform following:
- After each Ranorex UI affecting method have detected that 'global block flag' is set to false - it starts to look into 'global pop-up handler thread IDs list' maintained by PopupWatcher (which should be a singleton) in following way:
- Each UI-affecting Ranorex method determines if its thread ID corresponds to 'highest priority' thread from 'global pop-up handler thread IDs list' that is maintained by PopupWatcher and depending on result performs the following:
- If thread of certain 'Ranorex UI-affecting method' appears to be 'highest priority' thread from 'global pop-up handler thread IDs list' - method gets executed normally (as if 'global block flag' was set to false), so that all 'Rarnorex UI-affecting methods' of 'highest priority' thread get executed one by one resulting into the following:
- After all code of 'highest priority' thread (according to 'global pop-up handler thread IDs list') is executed and thread exits - PopupWatcher removes its ID from 'global pop-up handler thread IDs list' which results in execution of 'Ranorex UI-affecting methods' in next thread from that list (and that next thread becomes in turn 'highest priority' thread) so that all threads from 'global pop-up handler thread IDs list' get executed one by one - and then:
- After all threads from 'global pop-up handler thread IDs list' are executed and list becomes empty - PopupWatcher sets 'global block flag' to false again - and Ranorex UI-affecting methods from the main thread proceed execution until next pop-up is detected by PopupWatcher
Also: When dialog is being added to PopupWatcher it should be possible to specify parameter flag (bool parameter) that determines whether to look for dialog once - or infinite number of times. That is - when dialog is detected and handled then - according to new parameter value PopupWatcher will either stop looking for dialog or will start looking for dialog again (to execute handler each time when it detects dialog).
It will also make sense to add timeout (internal and/or user defined) for completion of thread from 'global pop-up handler thread IDs list' - after timeout exceeds thread gets terminated.
If you have read till the end - you are really a hero. If you have questions regarding a concept I have suggested - please ask either on forum or via private message.