find_best_control_matches causes ComboBox flutter

This is a tad bothersome to say the least. When i try to find a control by its name like:

control = win["name"]

all the ComboBoxes on my form flutter. It took me some serious drill down effort to nail this to:

ComboBoxWrapper.texts

which literally expands the combobox and collapses it again all in the name, it seems of finding three child controls that turn out to be:

uia_controls.ListViewWrapper - '', ListBox
uia_controls.StaticWrapper - '', Static
uia_controls.ButtonWrapper - 'Close', Button

But I’m looking for a panel in fact (Pane10), and I find it and it’s all good and the software alas has no title or name on that control, and so forth, but in finding it I have to endure unwanted ComboBox flutter?

What is the work around here? I’m curious. I will explore it some more, but I really don’t need all the ComboBox children to be checked when looking for a control unless I’m looking for one of those children. In short I kind of expect and guess this is a hope for, a setting through which I can say: Don’t expand controls in the best match search, the one I want is visible thank you.

Indeed the whole search seems a tad inefficient as find_best_control_matches calls build_unique_dict on all the controls in a window (hundreds) to build a name map for finding. But seriously it can break out and bail the minute it finds a perfect match I would guess.

I’m hoping I can find a better way to get the control for this pane that is reliable and avoid using this best_match approach.

[vasily-v-ryabov]

I’ve found right way to enumerate all combo box items for WPF without fluttering. See FindItemByProperty method of ItemContainerPattern. Remarks section tells that we can pass PropertyId == 0 to enumerate all items. This pattern is supported for ListView and other WPF containers as well (@airelil it might be useful for VirtualizedItems enumaration in explorer.exe’s ListView).

Unfortunately WinForms don’t implement this pattern provider, but we can use non-invasive workarounds from backend="win32".

The most complicated case is Qt5. Both ways are infeasible there. I couldn’t even get expanded/collapsed state. Getting texts are invasive, and nothing tells about any alternative way so far.

[bernd-wechner]

Ironically, looking deeper:

WindowSpecification.print_control_identifiers(self, depth=None, filename=None)

accepts a depth. And yet, it applies a depth check only to the print stage, building a list of all controls to the lowest depth first. Hmmmm … definite room for improvement here, to respect depth on the control walk, so that I might conceivably use depth as a means of finding Pane10 without ever seeing CombBoxes expand because they are one tier deeper than the the pane I’m after.

Ideally I suspect that the best_match criteria should include one called “expand = True” which we could pass to a best_match search or request in some manner, which conducts the best match search without expanding controls. Just on basis of the unexpanded controls.

But seriously it would be nice if the walk of controls also respected a depth setting rather than just the printing of them which does.