This project is read-only.

Toolstrip does not show correct content

Oct 18, 2010 at 6:27 AM


I have a problem accessing the components contained in Toolstrip of a GUI.
I can access the Toolstrip iteself but when looking into the content of the ToolStrip I do not get the correct components back.
Below is parts of my code.

Window w = BakgrundSteg.MainWindow;

 UIItemCollection coll = w.ToolStrip.Items;

This code for example returns three textboxes and one label when inspecting it in the debuger.
My toolstrip contains four textboxes four labels and three buttons.
The Name property of the returned items does not match the name I have entered in my code.


TextBox component = w.ToolStrip.Get<TextBox>(SearchCriteria.ByAutomationId(falt));
This code assignes null to the variable component.

Anybody else that are having problems with Toolstrips?
Everything else works fine, like accessing menus, windows and components within windows.
Our applications is however a heavy user of the toolstrip so it is not possible to continue testing using White if the toolstrip does not work properly.



Oct 18, 2010 at 8:07 AM
Edited Oct 18, 2010 at 8:09 AM


can you verify that all the elements you expect, are visible in UISpy or UIAVerify?

Does the missing elements on top level of the toolstrip or embedded in another element wich is part of the toolstrip.


can you try this:


AutomationElement element = w.ToolStrip.GetElement(SearchCriteria.ByAutomationId(falt));

TextBox component = new TextBox(element, w.ActionListener);


Oct 18, 2010 at 9:30 AM

Using UIAverify does give the same results as White.
This is the case even if I do a simple example only using the visual designer in VisualStudio.

If I however use Hawkeye_-_The_.Net_Runtime_Object_Editor_1_2_0_-_Professional it shows me the components I am missing.
They are hidden in some innerlist of the Toolstrip items array. But even with this tool the name property is not set correct.

Will this indicate that there are a generall uiautomation problem with Toolstrips.
I am using Windows XP and VisualStudio 2008.



Oct 18, 2010 at 10:27 AM


what UISpy or UIAVerify see are the elements which are visible for UIAutomation (and so for White).

Other Tools might show all user visible elements, (but this is not the same)

Elements which are visible for UIAutomation implement AutomationPeer.


So if UIAverify don't see these elements, UIAutomation and White don't see them.


In this case, you can try to use the new part of White CustomCommands  (i haven't tried yet)

if you have access to the developer, he might implement AutomationPeer for the element.

if you only want to click on it, you can click by position (relativ to the parent element)




Oct 18, 2010 at 12:37 PM

There is definitly a bug in the automation regarding some kinds of toolstrip.
I have tested some "public" applications with toolstrip/toolbar.
The ones that have an "old" toolbar without the four vertikal dots to the left can be very well automated. However if you have the "new" one like the one in Word 2007 it fails to show the correct content. Strange but not much to do anything about. I will probably have to look if I can use the "old" layout instead.


Oct 19, 2010 at 1:34 PM

I have  installed this patch that I have found

Now the Uiautomation of Word 2007 toolbars is ok but still not the most basic example created in VisualStudio 2008.
What can be wrong with the code created by VisualStudio?


Nov 4, 2010 at 7:19 AM

After testing a bit more I have found the following.
It has actually nothing to do with White just UIAutomation.

In my testapplication the toolstrip is automated perfectly correct as long as it does not contain items of the types ToolStripTextBox och ToolStripComboBox.
If the toolstrip contains items of those types that item and the items after  them (to the right) in the toolstrip are not automated correct. Everyting to the left of items of those types are automated correct.

Whats the problem with those types?
I have tested on both Windows XP and Windows 7.


Nov 4, 2010 at 9:08 AM


if this is a problem in UIAutomation, maybe there is a workaround for this. Have you tried the UIAutomation Forum from Microsoft?

Development for Windows Accessibility and Automation