TestStudio Standalone - DialogMonitor issue

[Max]

I just spent the last several hours trying to figure out why my coded step to handle a file upload dialog absolutely would not work when used in a data-driven test, and I feel that I should pass this bit of info along in case anybody else is running into similar issues.

My situation is as follows:

• I'm using the TestStudio Standalone version to test an ASP.NET Web Application.
• I'm testing a set of actions wherein a file input html control is used at some point.
  I wanted to extract the exact bits where the file input is handled so that I could reuse it in my similar tests.
• I made a small data-driven test to do this that inherits its data-source from its parent.
• That test would run properly on its first iteration but on any of the following iterations, nothing would happen once the file upload dialog popped up.

To make a long story short, I was following examples that I found online (mostly from these forums) where people were trying to programatically handle dialogs, and in most of those threads, "Manager.DialogMonitor.Start();" and "Manager.DialogMonitor.Stop();" were being called before and after (respectively) the dialog was handled in the code.  As it turns out, though, once "DialogMonitor.Stop();" is called, the DialogMonitor cannot be started again, which is why only the first iteration of my test was working.

Now that I think about it, most of those threads were probably posted by people using the TestStudio VS Plugin as opposed to the Standalone version.  Regardless, I never saw any mention of the fact that explicitely stopping the DialogMonitor in the Standalone version would render it unable to be started again.  As I also found out, it doesn't need to be explicitely started in the Standalone version either, but that's besides the point.

I did notice that in the TestStudio Standalone Documentation, the Start/Stop methods aren't included in the examples, but at the time, I presumed that was for the sake of brevity and merely glanced over it.  Perhaps I'm just blind, but in my humble opinion, it should be more obvious that these two methods should not be used when working with the Standalone version (presuming that the issue I ran into isn't a bug).  It may be a small issue, but it killed much of my productivity for a day.

[Anthony]

Hello Max,

You are correct; Test Studio Standalone version and VS plugin automatically handle the Dialog Monitor. You should not manually start and stop it, even if you're using coded steps to handle dialogs. That's why there isn't a mention of it in the user's guide for those versions. In fact, we recommend using the standard Dialog Handler steps and avoid code entirely.

The Dialog Monitor should be explicitly started and stopped in a purely coded test created with the Telerik Testing Framework, however.

Greetings,
Anthony
the Telerik team

[Max]

Hello Anthony,

Thanks for the response.  Having thought about it, it makes sense that the DialogMonitor would be started and stopped automatically in the Standalone version and VS Plugin.  My only wish is that I would have been able to find documentation explicitly stating that such is the case.  Alternatively, if attempting to start the DialogMonitor when it was already running gave a warning or threw an Exception (perhaps not a viable solution), then I would have immediately suspected that it was being started/stopped automatically and wouldn't have spent so much time trying to diagnose the issue.

As well, I was using the standard DialogHandler beforehand, but I decided to use coded steps to handle this situation instead.  My reason for this was that I wanted to be able to test a variety of file paths, including randomly-generated ones and the empty file path, and feeding the FileUpload DialogHandler an empty String will cause the test to hang once the FileUpload dialog pops-up.

That said, I've set up my coded step such that if the file path is null or whitespace, the dialog will use the Cancel button instead of the Open button which allows my single generic test to handle any type of input (as far as I've tested at this point).  Prior to using this coded step, I did just have a single test to explicitely handle the empty file path, but I'm trying to avoid making tests for individual edge-cases as much as I can when their test-path is effectively the same as that of valid input (with the outputted error message being the only real difference).

Thanks for listening,

-Max