Closed jarl-dk closed 11 years ago
If you can give me some directions on how to help the project implement this I would love to give it a try. Please give me an agenda, such as
In the UiaDLL you need to crate a new method with prototype this In the whatever.rb you need to replace the current implementation of ... with usage of the new method in the DLL bla bla bla...
Jarl
I guess you'd have to dig through the source code yourself to find out what should you exactly do to make it work. @leviwilson has been the one developing UiaDll adapter mainly, maybe he has some pointers for you.
@jarl-dk Currently with the :ms_uia
adapter, there are implicit dependencies on those controls having a native window handle to work with. If you open your WPF application and inspect it with Spy++
, I'm guessing that if you look at the radio control it does not have a native window handle (does Spy++
see the entire app as a single window?). I have intentions on moving the :ms_uia
in a direction where it does not have this dependency, and then it should work fine with your WPF application.
Also, are you using RAutomation
from the latest RubyGems, or from the latest master
branch?
Awesome...
Yes, latest master... I am also working on making a WPF equivalent of the WindowsForms test app to test against. I guess the intention is that the ms_uia shall work on both win_32 apps and wpf apps.
You are right. There is only one HWND in Spy++
Jarl
Yep, the problem lies right here: https://github.com/jarmo/RAutomation/blob/master/lib/rautomation/adapter/ms_uia/button_helper.rb#L7-L10
I plan on working on this in the next week or two. I'll keep you posted.
Sounds like you know what needs to be done.
Notice that my description says that #set?
does work, but #set
does not. Further if I find the radio button using a :id => 'buttonName'
the behaviour is different than when I use :value => 'Button Text'
, in the first case it crashes the whole ruby interpreter in https://github.com/jarmo/RAutomation/blob/master/lib/rautomation/adapter/ms_uia/functions.rb#L171 but in the seccond case it just can't find any children in https://github.com/jarmo/RAutomation/blob/master/lib/rautomation/adapter/ms_uia/functions.rb#L182 but that may be because there should be an additional when
statement in that case
construct.
I'll be glad if you could work on this during the next couple of weeks (I will gladly participate), I'll commit my WPF test app equivalently to the WindowsForm app. If you provide me commit access I'll do it on a branch which may be easier for both of us opposed to me forking and making a bunch of PRs
I was thinking of making the test suite such that it went through testing all the combinations of adapters and application types (WinForms, WPF)
Correct me if I am wrong but this schema illustrates what combinations should work, right?
App type \ adapter | autoit | win_32 | ms_uia |
---|---|---|---|
Windows Forms | X | X | X |
WPF | X | X |
Jarl
Thanks for helping us out :)
I can't see much of an hassle when it comes to accepting some pull requests instead of giving you full commit access. Sorry, i usually do not give out commit accesses so easily. It's funny that you asked, because i just gave today commit rights to @leviwilson after accepting his pull requests for quite some time now - i have shown him what i expect from the code and can trust him now that he will follow that path. I hope you understand the reasoning behind not giving out commit rights so easily.
When it comes to the combinations table - are you sure that Autoit should work with WPF? As far as i know, then it uses mostly Windows messaging as does Win32 adapter. I could be wrong of course.
To be honest, then i'd deprecate AutoIt adapter sooner or later anyway - it has been there from the beginning since it had most functionality before i polished Win32 adapter, which replaced it mostly (you can still use custom AutoIt functionality, but i have not seen anyone do that). So, what i'm saying here - ignore AutoIt adapter for sure.
I would be happy to ditch Win32 adapter too if MsUia would be ready, but the problem with MsUia is that it won't work on older XP machines, which would make RAutomation not to work out of the box by default.
OK, lets start the fork way.
Iam not sure at all of the table :-(
Let's make it simple - have only MsUia in mind when thinking in the context of WPF.
Agreed. I'm not sure adding a WPF app to the test suite will be necessary either. Once we have support for it, if there is an issue we can recreate with the WinForms app I'm guessing. If not, then we can get the WPF app into the mix at that point.
@jarmo what makes MsUia not work out of the box for XP? Only thing I can think of is the .NET dependency. Other than that, what am I forgetting?
There was some Windows Update which was needed. Can't remember exactly. Wasn't you the one with who we tried that out long time ago?
Ahh, your memory is much less crappy than mine :+1: https://github.com/jarmo/RAutomation/pull/34#issuecomment-10090950
You said: "When you don't have .NET 4 it fails to load UiaDll.dll and says that there was a bad image format." - i wonder if it's possible to catch that error from Ruby side, print out some meaningful message to the user and then exit?
I'm guessing that's true...as we can detect if FFI fails to load UiaDll.dll
. I can explore this at some point.
I've created a separate issue ^ for that. Let's not make it priority one :)
@leviwilson : How can you test against a WPF app if you don't have a WPF app (in the test suite) to test against?
Because it shouldn't matter when I remove the HWND dependency in the adapter whether it's a WPF application or a WinForms application as it will work solely with UIA.
Yes, but testing against a WPF app will serve as a verification/proof that the switch (away from HWND) is complete.
@jarl-dk I just added a handful of commits (73f4a06ec25d885521b6) that should give us a lot of headway with working with controls that do not have HWND
values. Let me know if this resolves your issue.
Another problem came up using the latest master:
Function 'IsEnabled' not found in [C:/projects/RAutomation/lib/rautomation/adapter/ms_uia/../../../../ext/UiaDll/Release/UiaDll.dll] (FFI::NotFoundError)
c:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.7.0-x86-mingw32/lib/ffi/library.rb:251:in `attach_function'
C:/projects/RAutomation/lib/rautomation/adapter/ms_uia/uia_dll.rb:113:in `<module:UiaDll>'
C:/projects/RAutomation/lib/rautomation/adapter/ms_uia/uia_dll.rb:7:in `<module:MsUia>'
C:/projects/RAutomation/lib/rautomation/adapter/ms_uia/uia_dll.rb:6:in `<module:Adapter>'
C:/projects/RAutomation/lib/rautomation/adapter/ms_uia/uia_dll.rb:5:in `<module:RAutomation>'
C:/projects/RAutomation/lib/rautomation/adapter/ms_uia/uia_dll.rb:4:in `<top (required)>'
C:/projects/RAutomation/lib/rautomation/adapter/ms_uia/control.rb:52:in `exist?'
C:/projects/RAutomation/lib/rautomation/adapter/ms_uia/radio.rb:11:in `exist?'
I am working on a equivalent WPF app for testing you are welcome to pull it from here: https://github.com/softace/RAutomation/tree/improvements
@jarl-dk be sure to run a rake install
after you pull the latest. The DLLs are not checked into the repository, they are built by msbuild. That method is defined in the UiaDll.cpp
here.
Thanks a lot. My fault, so sorry. That certainly made a big difference. I can now interact with the WPF app (at least radio and text_field).
Thank you.
The tests are working on a WindowsForms application, and there the spec file succeeds. When I use RAutomation on a WPF application
MsUia::Radio#set
fails and claims it cannot file the control.However most other methods works file such as
#set?
,#control_name
#class_name
, and so on.