Leaderboard

Because LabVIEW doesn't use Windows objects, so LabVIEW controls have no object ID. Only LabVIEW knows where the controls are. To OS & other applications, there is nothing on the front panel. Only 2 exceptions: ActiveX & .Net containers. The containers are child windows. Therefore they should have an object ID.

at one point NI put effort into this...I never got around to using it but its always been on my list https://forums.ni.com/t5/NI-Labs-Toolkits/LabVIEW-UI-Automation-Tool/ta-p/3521765 The downside is that its clearly abandoned. But if it does what you need..

Zou is probably right. LabVIEW does a lot of nonstandard things in their UI drawing, likely so they can be more easily crossplatform with Mac and Linux. Have you thought about possibly leveraging a LabVIEW EXE to get information about the position of other controls? I could imagine a LabVIEW EXE that opens an application instance to an already running EXE, and then get reference to VI front panel, then references to the controls themselves. It might be possible at that point to get the position of a control, based on the control label in the VI. Then it might be possible for your tool to get the positioning of a control, based on the name. But at that point one could make the argument to just use LabVIEW to control LabVIEW. Nothing sounds like a good solution.

DVRs are in 2009. I have thought twice about upgrading due to new features. Once was for the native JSON but it was so useless in the real world I stayed with my own. The second was the Start and Wait On Asynchronous call. My architectures could benefit from it but had no pressing need since I already have the tools to achieve the same result, Many people rave about self indexing tunnels. It was (is?) just some syntactic sugar for the old style so there were no performance benefits but It looked a bit nicer - hardly worth the risk of updating to a new version or keeping old and new versions of the code base. Some features (like the live moving of structures and wires) I detest but will suffer it if the needs must. Anything. that forces me to change my work-flow (like quick drop) I resist vehemently so you can add any of those to the list of why not upgrade. Be aware, though. I produce toolkits so the minimum version is important so that as many people can use it as possible. This is an incentive for me to go back as far as possible. It just happens that 2009 is pretty much bullet proof, no random busy cursors slowing me down and arguably still the fastest executing code. When it first came out I was so pleased that the pain and suffering of the buggy 8.x series was over and disappointed with most of the later versions for the same reasons.

I've been playing a bit with AutoIT (https://www.autoitscript.com/site/autoit/). But I've faced the same problem - there is no way, other than screen coordinates, to refer to any GUI items in LabVIEW. What exactly are those "Object IDs" and where do they come from, and why they are not present in LabVIEW - those questions are beyond my knowledge. But if someone was succesfull with GUI testing in LV, I'd be interested to hear that too