Forum Discussion

Contributor

8 years ago

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...

jmassey
8 years ago
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.

tristaanogre

Esteemed Contributor

8 years ago

You're showing Basic methods... Could you give us the advanced view of both properties and methods? There may be native stuff that is not showing up in the basics that we might be able to leverage.

jmassey
Contributor
8 years ago
I've dug through all the properties and haven't seen anything that looks useful for getting at the individual controls. I can't even see anywhere where I might be able to pull out their individual dimensions / coordinates, or get a listing of the selections in the combobox or directly set which index is its current selection, or anything.

The frustrating thing, like I say, is that in other, older parts of the app where these WinForms controls stand on their own, I can automate them just fine. But something about them being wrapped in the WPF Windows Forms Host just makes everything below that opaque.

I'll paste in here for you to look at, though:
- Marsha_R
  Moderator
  8 years ago
  Have you tried recording a test and just clicking on those fields? That would show you what TC thinks the objects are.
  - jmassey
    Contributor
    8 years ago
    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.