Hi,
We have been seeking a way to automate our UI regression testing.
Our test engineer has designed our automation setup using the Robot Framework in
Python. To make this scripting possible, it uses the UI Automation standards from Microsoft.
When applications don't implement the Microsoft IAccessible interface, automation tools derive a best guess of a legacy name to apply to form controls based on the sibling relationship between labels and interactive controls, in that, most likely a label will precede the text box, etc that it relates to.
We soon learnt that this then makes the declaration order of form elements critical to the naming and also learnt that the declaration order on our forms can be wildly wrong (most were initially made 15+ years ago - and a lot of time the developers must have just duplicated the parts before adding labels).
I assumed it would be easy to be able to manually apply a legacy UIA name to the form controls using some set of PlatformFunction's to achieve settings UIA properties on the associated HWNDs. It is not easy or as far as I could tell possible.
The accessibility properties of IAccessible appear to be read-only at runtime.
We tried using SetWindowTextA (as another legacy naming fallback is it uses GetWindowTextA result as the name). But this only helps for form controls that are text related, it didn't apply to a radio button group for example.
Also this has the downside that it actually changes the control's content.
One out-there idea was to intercept the
WM_GETOBJECT message, but that all seemed too much.
Destroying the form in the composition view and rebuilding was fraught with possibility of mistakes.
I tried manually changing the abtBuildInternals, but my changes got overwritten when anything was changed in the Composition view and then saved.
But I sat down and dug thru the Abt code and eventually got to area on Part Builders.
Although not fully working out the relationship between all these classes, I soon came across AbtReorderSubpartBuilders.
It seems as though this is entirely here to support Tab Ordering.
It never occurred to me that tab ordering I guess is inherent in the control creation order.
Please let me know if I am "doing this the long way around" or any other different method.
But I solved this by in the Composition view by:
* Setting Tab Group & Traversal as true on every element to re-order.
* Re-ordering the tab order.
* Save the Part.
* Setting Tab Group & Traversal back to false on every element done in step 1.
* Save the Part.
You can see an example of the problem and what the above solves in the attached PDF.
Hope this info may help someone in a similar spot in the future.
Regards, Matt.