Sign in to follow this  
Followers 0
Henrik

Obtaining Constant Control Identification

12 posts in this topic

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."


Ignorance is strength.

Share this post


Link to post
Share on other sites



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

Share this post


Link to post
Share on other sites

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


Use Mozilla | Take a look at My Disorganized AutoIt stuff | Very very old: AutoBuilder 11 Jan 2005 prototype I need to update my sig!

Share this post


Link to post
Share on other sites

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.


Ignorance is strength.

Share this post


Link to post
Share on other sites

What is the name of the program?


Who else would I be?

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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'.


Ignorance is strength.

Share this post


Link to post
Share on other sites

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.


Ignorance is strength.

Share this post


Link to post
Share on other sites

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 :) )?


Ignorance is strength.

Share this post


Link to post
Share on other sites

#10 ·  Posted (edited)

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 by Jon

Share this post


Link to post
Share on other sites

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


Ignorance is strength.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0