This project is read-only.

Help - Very slow to get Visual Studio menu bar

Oct 25, 2008 at 7:37 AM

We developed some addins for Visual studio, and want to use white as test tool. Here is the code:

Application app = Application.Launch(@"devenv.exe");

Window form = app.GetWindow("Start Page - Microsoft Visual Studio (Administrator)", InitializeOption.NoCache.AndIdentifiedBy("devenv"));
MenuBar menubar = form.MenuBar;

Menu menu = menubar.MenuItem("Tools");


Functionally, this code works fine, however, it takes more than 1 minute to get the menu object! Maybe the UI of Visual studio is too complicated, do you have any suggestions?

BTW, is there any method like UIItem.FromPoint() to get a item from known location? AutomationElement has this kind of method, and it's very fast.



Oct 25, 2008 at 8:51 PM
Have you checked this page in white documentation.
Oct 26, 2008 at 1:49 PM
Yes, I have read that article. As you can see from the code above, I already used this trick(I only need the main window, so I used devenv as id).
I'm not sure if the KillAndSaveState will do the same thing with ApplicationSession.Save.

My problem is, when I first run this piece of code, it takes more than 1 minute, and I have lots of test steps, I need to debug my test case, but I'm afraid I cannot just sit there for 50 minutes to watch it finish the first test pass. Isn't it a performace bug?
Oct 27, 2008 at 7:54 AM
Edited Oct 27, 2008 at 7:58 AM
Is this a performance issue?
Yes it is. Based on my understanding this is reason:
UIA implementation for WinForm and Win32 (eg. VisualStudio) is via client side providers. In other words it works via Windows messages. Hence when one tries to find a UIItem using white, white finds AutomationElement using UIA. Client side providers have to evaluate every AutomationElement, but every fetch of AutomationElement is a round trip. Same thing works extremely fast for Server side provider, which is how WPF providers are implemented.

If it is possible you should do something like closing un-necessary toolbars, tools boxes and editor windows in Visual Studio manually first. Then start the test to get faster response. More the number of windows longer it would take.

In long run, if it is possible, I would give server side provider approach for WinForm/Win32 a shot. Not sure at this point how successful it would be.

UPDATE: There is another approach to solve this problem, which is by using RawTreeViewWalker. By using this entire parts of UIAutomation tree can be ignored while finding based on intelligent guesses.
Oct 27, 2008 at 11:32 AM
Edited Oct 27, 2008 at 11:34 AM
> BTW, is there any method like UIItem.FromPoint() to get a item from known location? AutomationElement has this kind of method, and it's very fast.

Well you can create AutomationElement.FromPoint() and then create a UIItem from the AutomationElement you have created (new UIItem(AutomationElement, ActionListener). This will create an UIItem, i.e. if the element is a Button the UIItem will not be a button. But if you are sure of what type of object that is you can create a button instead of a UIItem, with the same construtor. You may also check the ControlType of the AutomationElement you have retrieved from the point and create an Item of that type (i.e. if ControlType == Button you create a Button, etc..)
I'm using this and had no problem with it.. at least for now.

Hope this helped
José Tavares
Oct 27, 2008 at 1:59 PM
Edited Oct 27, 2008 at 2:34 PM
Thanks for your help. I tried to use AutomationElement itself, and it's also slow. So this is not an issue in white. I will consider other workarounds.
Nov 9, 2008 at 12:41 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.