[invalid] Au3Info, Control Class Instance value.

[MvGulik]

Working with Au3Info and RanorexSpy I noticed that in relation to the returned Control instance value:

- Au3Info seems to (only) return a absolute Control instance value.

- RanorexSpy seems to (only to) return a relative Control instance value.

In the case of the target GUI I'm working on (a Qt GUI btw). Where the Controls seems to be dynamically being destroyed and re-created (when needed). A absolute Control instance value in this case is not so useful as a relative Control instance value.

Any thoughts or comments on this?

---

Considering the control handles stay the same. Something else other than "dynamically being destroyed and re-created" is probably going on. Don't think this changes the potential usefulness of also returning relative Control instance values in Au3info.

(Although, it probably to much work for a to minor feature. As its probably just a Qt GUI thing.)

Edited January 24, 2012 by MvGulik

[numdig]

What do you mean by "control instance value", is that the small integer, typically "1", "2", etc. ? And what do you mean by "relative" and "absolute"?! With screenshots, or at least string exemples/samples it would be easier to understand.

I've seen a case where an ATL component would have a different CLASSNAME each time it is run, but I don't understand your point regarding the instance number.

Edited January 26, 2012 by Chess

[jvanegmond]

I believe the instance number is something AutoIt made up to make it easier to handle several controls which share properties. The indices are defined based on how they are returned from a Windows function (not sure which AutoIt uses). This in turn is based on the order in which they are created, but I am not sure if the Windows function used guarantees this or just happens to have that behavior consistently across (almost?) all versions of Windows.

How RanorexSpy defines instance numbers, I have no idea.

A simple solution: Build your own system of identifying controls matching RanorexSpy behavior. Release it into community.

Edited January 26, 2012 by Manadar

[MvGulik]

control instance value: Yep that small integer, typically "1", "2", etc.

relative/absolute: Relative to parent control. (With absolute being relative to window or just the order there found it.)

- - -

Its probably not RanorexSpy who is actively defining the numbering, but the system it is using for retrieving the Qt GUI data. (although I have no proof here.)

Qt has a 'Qt accessibility' feature -> http://developer.qt.nokia.com/doc/qt-4.8/qt4-accessibility.html

And RanorexSpy is probably uses 'Microsoft Active Accessibility' (MSAA) or 'Microsoft UI Automation' (UIA) to retrieve the Qt GUI data.

The numbers seem parent-child level based, or: at every new/deeper level the counting start with again with one.

Considering AutoIt can't read this data on its own (or: without some external help), I don't think It really relevant how or what its returning. (It just allowed to do something that is not intentional.) (Its probably just enumerating a list, where the location of the elements have no strict, or useful, meaning.)

... <-[bug prevention test]