Obtaining Constant Control Identification

[Henrik]

The app I'm working with has several unnamed buttons with no text on them. I tried using the AutoIT Window Spy to obtain a unique ID for each button ('Class' entry under 'Last Control Under Mouse').

The problem is, for some buttons, the number appended at the end of a class name varies during program execution. E.g. a button may have Class: Button31 immediately after the app is started, then change to Button74 later (after the app has instantiated more controls).

Is this a feature with AutoIT? Is there a workaround to get some kind of non-varying handle on the control (the handle is needed for ControlClick()'ing)?

H.

"It's not a bug, it's a feature."

[Matt @ MPCS]

The class of a button normally doesn't change during the application's execution, what is probably happening is there are multiple buttons stacked and it shows different buttons at different times. As far as I know there is not a command to get the control at a specific location on the screen. You could however write a UDF that does that using the WinGetClassList, and ControlGetPos functions. To do this you just need to get the position of the button you know about and loop through all of the controls that have the same position and click them... see what happens. Someone else might have another (better) solution though. It should work if no one else has any suggestions.

*** Matt @ MPCS

[CyberSlug]

The newest betas of AutoIt support a ControlID number shich should stay fixed. However, it's possible that there are separate controls that are hidden/shown or deleted/created.

The newest version of AU3_Spy should show something like:

Control ID: 128

Class: Button6

Text: 4

[Henrik]

The newest betas of AutoIt support a ControlID number shich should stay fixed. 

Using the current beta (3.0.103), two buttons (in the same window) get identical ControlID's ! I assume this is a bug, IMHO ControlID's should be unique within windows (note the 2 buttons in this case have different functionalities and disjoint locations within the windows).

The class of a button normally doesn't change during the application's execution, what is probably happening is there are multiple buttons stacked and it shows different buttons at different times.

The button in question is not stacked. Apparently the SysTabControl32 in the window causes the class of the button to change each time a new tab is instantiated (even though this button is not located on the tab control).

H.

[this-is-me]

What is the name of the program?

[Valik]

Larry, yes. It's still undocumented, but there:

ControlGetHandle("Title", "text", "Control")

[Henrik]

ControlGetHandle("Title", "text", "Control")

<{POST_SNAPBACK}>

Using ControlGetHandle() with one of the two buttons having the same ControlID (their "texts" differ) yields a handle to the other button!

That is,

dim $BtnHandle = ControlGetHandle($JetImage,"x",1119)
if @error then msgbox(0,"EEK!","could not get handle")
ControlClick($JetImage,"",$BtnHandle)

will click the button having ControlID 1119, but another text ("1").

Guess I will have to MouseClick the buttons. Not so neat as ControlClicking

The program's name is 'designjet scan'.

[Henrik]

I may not understand.. if it has unique text do...

ControlGetHandle($JetImage,"x","unique text here")

<{POST_SNAPBACK}>

My mistake, I thought the 2nd argument was the text on the control, not in the window.

Unfortunately this window has many controls with the text "x", the uniqueness I thought of is only between the two buttons with identical ControlID's.

[Henrik]

Sometimes when controls are on "tabs" this happens...

<{POST_SNAPBACK}>

OK, so instantiating a tab page may result in the number part of a control's class being changed and/or several controls getting the same ControlID.

Is this a feature with AutoIt or is it a Windows thing (i.e. is it fixable or not )?

[Jon]

If the control IDs are the same then it's the other programs fault - it is possible to give things the same control ID and windows doesn't complain, but it is very silly (except for labels where it is quite common).

If a combination of classname, control ID and text are not enough to ID this control then....

Edited October 26, 2004 by Jon

[Henrik]

it is possible to give things the same control ID and windows doesn't complain, but it is very silly

<{POST_SNAPBACK}>

Thank you, I needed that hint. The culprit in my case is MS VC++ resource editor, which may reuse a control ID in several child windows.

This solves my problem, as I can have 'my' programmers enforce unique control ID assignment

For programmers: In a MS VC++ 6.0 project, these ID's are located n resource.h

[Jon]

Thank you, I needed that hint. The culprit in my case is MS VC++ resource editor, which may reuse a control ID in several child windows.

This solves my problem, as I can have 'my' programmers enforce unique control ID assignment 

For programmers: In a MS VC++ 6.0 project, these ID's are located n resource.h

Yeah, sometimes in the autoit project when I've been deleting resource strings you can sometime see that the same ID has got reused in error by the compiler. It can go unnoticed for weeks!