ButtonWrapper

[johnyCZS]

Hello,

this question is more out of my curiosity then out of need. But I stumbled upon a error:
AttributeError: "ButtonWrapper" object has not attribute "get_toggle_state".

This error shows after:

fpoWin.get_toggle_state()

fpoWin is a children of a win32 backend application which I accesed by:

dsk = Desktop(backend = "win32")
win = dsk.windows(title = "sometittle")
fpoWin = win[0].children()

In pywinauto documentation I found that get_toggle_state() is a method available to class pywinauto.controls.uia_controls.ButtonWrapper

But when I use it I get error saying that its not available for ButtonWrapper.

What am I missing here? Does it need to be accessed and specified by app.YourDialog.get_toggle_state() rather then using .children() method?

[junkmd]

@johnyCZS

Hi!

We have met again.

In conclusion, the reason is that the backend is set to "win32".
To replicate a situation similar to yours, I simulated the GUI of an application in my environment as the target and ran the following steps:

>>> # Python==3.10, pywinauto==0.6.8
>>> import pywinauto
>>> from pywinauto import Desktop
>>> import pywinauto.controls
>>> # win32
>>> win32dsk = Desktop(backend="win32")
>>> btn = win32dsk.windows(title='some title')[0].children(class_name='Button')[0]
>>> isinstance(btn, pywinauto.controls.win32_controls.ButtonWrapper) 
True
>>> isinstance(btn, pywinauto.controls.uia_controls.ButtonWrapper)   
False
>>> btn.get_toggle_state
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'ButtonWrapper' object has no attribute 'get_toggle_state'
>>> # uia
>>> uiadsk = Desktop(backend="uia")
>>> btn = uiadsk.windows(title='some title')[0].children(class_name='Button')[0]
>>> isinstance(btn, pywinauto.controls.win32_controls.ButtonWrapper)
False
>>> isinstance(btn, pywinauto.controls.uia_controls.ButtonWrapper)
True
>>> btn.get_toggle_state
<bound method ButtonWrapper.get_toggle_state of <uia_controls.ButtonWrapper - ...>>

The wrapper class instance that returns from methods of Desktop will be based on the backend used. If the backend is set to "uia", it will be an instance of a class defined in uia_controls. If the backend is set to "win32", it will be an instance of a class defined in win32_controls.

In your way, win32_controls.ButtonWrapper was returned, which is why specifying get_toggle_state resulted in an AttributeError.
The get_toggle_state method exists only in uia_controls.ButtonWrapper.

If you want to use a class with a different backend locally, you can instantiate it by passing values to the ...Wrapper's constructor.

>>> from pywinauto import win32_element_info
>>> from pywinauto import uia_element_info
>>> win32btn = win32dsk.windows(title='some title')[0].children(class_name='Button')[0]
>>> win32btn                                    
<win32_controls.ButtonWrapper - 'button title', Button, ...>
>>> win32btn.element_info
<win32_element_info.HwndElementInfo - 'button title', Button, ...>
>>> win32btn_elminfo = win32btn.element_info 
>>> win32btn_elminfo
<win32_element_info.HwndElementInfo - 'button title', Button, ...>
>>> uiabtn_elminfo = uia_element_info.UIAElementInfo(win32btn_elminfo.handle)      
>>> uiabtn_elminfo
<uia_element_info.UIAElementInfo - 'button title', Button, ...>
>>> uiabtn = pywinauto.controls.uia_controls.ButtonWrapper(uiabtn_elminfo) 
>>> uiabtn
<uia_controls.ButtonWrapper - 'button title', Button, ...>

I had actually planned to use this as a topic for my technical article in the future.

I hope this helps.

[johnyCZS]

Hello!

Yes we do. I was expecting and answer on this topic from you.

Now when I look at it seems obvious that it wouldn't work when the backend I used was win32 and it literally says in the class UIA.

Thanks for clarifying Wrappers, I couldn't find any information on how to use Wrappers on the official documentation. It very well could be just me, but I find the information there on how to start quite confusing and it doesn't mention other ways to use pywinauto such as those we both use in our projects. So most of the time in my project is basically trial by error and seeing what works without 100% confirmation why it works which can be dangerous.

With that said as a junior dev I'm looking forward to your article and learning more about the ways pywinauto can be used.

[junkmd]

Hi!

I'm glad if I could be of help.

I think that the reason why these usage patterns are not documented is because pywinauto has strong environment-dependent characteristics by its nature.

In other libraries, it is common to describe use cases in interactive and doctest-executable format within docstrings.

However, I think such things are difficult, even for a simple script that launches "notepad.exe" or "calc.exe" and grabs their windows by their titles.
Because in my Japanese Windows interface language environment, the window titles would not be 'Untitled - Notepad' and 'Calculator', but '無題 - メモ帳' and '電卓'.
Furthermore, when trying to ensure behavior using doctest, an existing process or a new process is required. And it is necessary to consider the teardown.

• The tests of this package are written with the assumption that the OS Windows interface language is English.
  And, the functionality of this package is ensured through the tests executed in a CI environment where the OS Windows interface language is set to English.

  • From wiki;

  Known problems

  If your OS Windows interface language is not English, you may experience some failures because several tests still use a language-dependent notepad.exe as an app under test. Reducing the number of such tests would also be a valuable contribution.

So, instead of considering contributing to this repository in the first place, I plan to introduce use cases of pywinauto in my personal technical articles.

[johnyCZS]

We faced a similar issue with our project because it runs on machine worldwide and the OS language is dependent on the country language country it runs in. Even tho the program we automated is in default in english some of the messages and buttons emitted by the program are in the users OS language.

We were able to solve this issue by specifying the windows or buttons etc... by using elements that are either not language dependent or simply using its indexes in children() lists which is has its issues but it works on all languages.