Settings.ExecuteCommandTimeout question

[macon]

I have a VS unit test that needs to alter the value of Settings.ExecuteCommandTimeout before doing a Get<>. I'm updating the Settings via the following code:

ActiveBrowser.Manager.Settings.ExecuteCommandTimeout = 8888;

When I initially created the Manager object I used a Settings object that set the ExecuteCommandTimeout property to 4444. So 4444 is the background setting and my override is 8888.

For testing's sake I'm using the following code in my unit test to verify that my Setting.ExecuteCommandTimeout is not being used:

resultControl = Get<HtmlControl>(new HtmlFindExpression("TextContent=" + textContent), false, 1000);

// check value of resultControl.Wait.Timeout in debugger

resultControl.Wait.ForExists(); // this line takes ~4444ms

If just before this code I check in the debugger the following:

ActiveBrowser.Manager.Settings.ExecuteCommandTimeout

ActiveBrowser.Frames[<all>].Manager.Settings.ExecuteCommandTimeout

where <all> are all the frames in my Frames collection, I see that the ExecuteCommandTimeout is 8888!

So my question is what am I missing to get the Get<> methods to honour the new timeout value?

Thanks in advance,

Matt

[Cody]

Hi macon,

Let me see if I understand what's going on using this code sample:

1. // Initialize
2. Settings mySettings = new Settings();
3. mySettings.ExecuteCommandTimeout = 4444;
4. Manager mgr = new Manager(mySettings);
5. // Wait for Result element to exist which can take a long time
6. Manager.Current.Settings.ExecuteCommandTimeout = 8888;
7. resultControl = Get<HtmlControl>(new HtmlFindExpression("TextContent=" + textContent), false, 1000);
8. // check value of resultControl.Wait.Timeout in debugger
9. resultControl.Wait.ForExists(); // this line takes ~4444ms

You using something like lines 1-4 for your test initialization. Then a part of your test is using lines 5-9. Have I got it so far? You then break in your debugger on line 7 and discover the ExecuteCommandTimeout has a value of 8888. Isn't that what it should be as a result of line 6? Am I missing something?

All the best,
Cody
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.

[macon]

Thanks for reply.

You've nearly got it completely! I break on line 9 and check the value of:

resultControl.Wait.Timeout

and it's still set to 4444.

Although I notice one difference in your code to mine; you're setting Manager.Current.Settings.ExecuteCommandTimeout but I'm setting Manager.Settings.ExecuteCommandTimeout. I wonder if that's the problem.

In the meantime I have got it working but with a different solution. I noticed that after I changed ExecuteCommandSettings to 8888 the Browser.CommandTimeout property was still set to 4444. This was also the case for each of the Browsers in the Frames collection. After setting all of those CommandTimeout properties to 8888 and doing a Get<>() it then worked!

I wonder if using the Browser.Current.Settings will solve it. Watch this space.

Thanks

Matt

[macon]

In response to my last post: using Manager.Current.Settings made no difference. So I still have to set the CommandTimeout of ActiveBrowser and all Browsers in the Frames collection to allow Get<> methods to use the new timeout setting.

Matt

[Cody]

Hi macon,

I think I begin to understand what may be happening. The Get<> function is part of the HtmlElementContainer class. This is normally used in the Pages class which is automatically generated by WebUI Test Studio and can be used in something like this:

Pages.RRComNewsSportsEmail.FrameAdsonarServe739773.Get<ArtOfTest.WebAii.Controls.HtmlControls.HtmlAnchor>("TextContent=^Take Advantage ", "tagname=a");

In this particular sample, RRComNewsSportsEmail is the name of web page and FrameAdsonarServe739773 is the name of an IFrame contained on that page. Both derive from the HtmlElementContainer class. Thus the Get<> is acting on an IFrame, which has a Browser object associated with it. In order for the ExecuteCommandTimeout setting to be active for my Get<> I have to be certain to set it on the correct Frame object.

You mentioned you are dealing with Frames and thus I suspect you need to take the time to determine which frame your Get<> is acting on and be certain you are setting the ExecuteCommandTimeout value on right one, which you effectively doing to hitting ALL of the frames all at once.

Make sense?

Sincerely yours,
Cody
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.

[macon]

It's a bit of a shame that setting the ExecuteCommandTimeout doesn't have the effect documented. Reading the (poor) documentation it states that Get<>() commands use that setting for their timeout. It's a pain to have to have to set that and then to drill down to all the Frames and set their CommandTimeout property.