Cannot access ToolStripDropDownButton inside ToolStrip

[Dario Ramos]

My application GUI is made using a mix of vanilla Winforms controls, plus some custom controls made by extending Winforms controls.

Here's the part of my GUI tree which concerns this issue:

mainWindow (extends System.Windows.Forms.Form as usual)
        |
        |---> viewPanel ( System.Windows.Forms.Panel )
        |              |
                       |---> toolStrip ( extends System.Windows.Forms.ToolStrip )
                       |           |
                                   |---> tddMode ( extends System.Windows.Forms.ToolStripDropDownButton )
                                   |

The above corresponds to what I know from just looking at my code. Using White, I can get as far as toolStrip, but I just cannot access tddMode.

If I look at my GUI with UISpy, everything looks fine upto toolStrip, but if hover over tddMode and click Control, I get this error in the UISpy console:

Element : Element details not available.
Name : TreeValidationException
Message : UI Automation tree navigation is broken. The parent of one of the descendants exist but the descendant is not the child of the parent
Stack Trace :    at UISpy.Base.Tree.BuildTree(AutomationElement element)
   at UISpy.Base.Tree.BuildTreeAndRelatedTrees(AutomationElement element)

I can look at other controls inside toolStrip; I only fail to see those that, like tddMode, are of type CustomControls.ToolStripImageDropDownButton (my class which extends System.Windows.Forms.ToolStripDropDownButton).

I read in other posts that if UISpy cannot see the control, White won't see it either.

Any advice?

[Jake Ginnivan]

That is rather odd. What is your custom control doing?

 

It looks like the toolstrip is not exposing tddMode as a child in UI automation properly.

 

Could you attach a small sample winforms project which replicates this issue then I can try to look into it.

 

I got nothing off the top of my head

--
You received this message because you are subscribed to the Google Groups "TestStack.White" group.
To unsubscribe from this group and stop receiving emails from it, send an email to teststack_whi...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dario Ramos]

I just finished making a sample Winforms app with the same structure I described earlier, but just the controls I mentioned (there are actually more controls in the ToolStrip). But UISpy identifies tddMode correctly.

So it seems the problem is not in tddMode's class, but maybe in my custom ToolStrip class.

Work time is over, so tomorrow I'll give it another go. I'll add the remaining controls to the Toolstrip and see how it goes. I just wanted to let you know this in case it gives you a lead.

[Dario Ramos]

I managed to reproduce the issue using vanilla Winforms controls and a class which extends System.Windows.Forms.ToolStripControlHost.

The problem appears when you put an instance of a  subclass of ToolStripControlHost inside a ToolStrip.

I put a MonthCalendar control inside one of those hosts, put it inside a ToolStrip, and added a button drop down below. When I try to identify the button using UISpy, I get the same error my app does (that one about children and descendants).

I attached the sample app. Please ask me if you need anything else.

[Dario Ramos]

Any news about this? A suggested workaround? Is there any way I can help? Wanna get back to writing tests...

[Jake Ginnivan]

This looks like an unsupported scenario in Windows Forms, there is nothing White can do if the underlying framework fails to work properly.

 

After the next release of White, I will be trying to port White over to v3 of the UIA framework. Currently White is using v2, unfortunately it has been a lot of work to get White to the stage where I can move it over.

 

I have tried your application using ‘Inspect.exe’ which comes in the windows SDK I think. It should be installed at C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin. Inspect uses v3 of UIA.

 

It seems to be able to find the controls without throwing errors, so this issue has likely been fixed.

 

Cheers,

Jake

[Dario Ramos]

I'm glad I kept writing more tests using White, then. Aside from this scenario, it's worked wonderfully. I'll be eagerly waiting for the new versions.