Automate Windows Forms controls in WPF FormsHost
I think maybe this narrower problem might be all I really need to get addressed, vs the more complex question I asked the other day:
We have in our app some old Windows Forms custom controls that are mostly just compositions of some simple controls, e.g. a combobox and a textbox together. In the purely Windows Forms parts of the app, when TestComplete finds these controls, it can dig down in and automate each component control properly, so e.g. I can 'ClickItem' on the combobox and 'SetText' on the textbox.
However, in some newer parts of the application, we are moving to WPF, and in order to be able to continue using these old custom controls (so that 'look and feel' / functionality is consistent), they are placed inside a Windows Forms Host control. The problem is that Object Browser will not drill down any deeper than the WPFObject("FormsHost"), so I can't really automate the control beyond doing coordinate clicks on the parent window. That will get me by when it's a textbox, but it makes things like a combobox very painful to automate.
Is there any way to fix this, and get TestComplete to recognize the individual controls being hosted by the FormsHost? I know that it knows how to work with them when they're not in the FormsHost, and the FormsHost is not itself any kind of custom or weird thing. It seems like this should work.
Here's a quick screenshot so you can see the type of thing that I mean:
So I think after much more poking around and enlisting the help of one of the devs, I think (hope!) that I've got this all sorted. Thanks Marsha and Robert for the help.
- First / most important thing: What I hadn't noticed is that that all of these controls are listed twice in the object browser:
This is obviously much, much easier to get at. I can also use 'Keys' or 'SetText' on the textbox like I'd expect to. Huzzah!
- I was actually eventually able to find a property I could dig through to get at these in the first listing - under (FormsHost).NativeClrObject.Child, and from there digging through layers of controls, to get to them. Luckily, now I know I don't need to do that, but at least I can keep it in mind in the future.
- For some reason that the person currently working on this new form doesn't know (they didn't make the original control), that dropdown is actually a menu button. When I record a script, it just clicks on the button, and then records a coordinate click. However, I can directly set a property on the parent control to switch between options of the dropdown, so that will get me 'good enough' for now.
So the main lesson learned here was knowing to look for the top-level (below the window) 'WinFormsAdapter' entries in Object Browser, instead of working down through the tree like for most objects. And then the secondary thing was the unusual menu button.
