Sign in to follow this  
Followers 0
lizardly

Control Class Varies (Revisited)

8 posts in this topic

This is a follow up to my question regarding Class Names yesterday.

I'm Testing a .net app and occasionally when I launch it via AutoIT or from the Desktop Icon

and look at controls using "AutoIT Window Info" the class name will have changed from

WindowsForms10.SysTabControl32.app.0.3ce0bb8

to

WindowsForms10.SysTabControl32.app.0.5c39d4

it stays consistent as one of the two while the app is active.

I still can't figure out what is causing this shift. 90% of the time it's the .3ce0bb8 value

but if it does change on a subsequent run, my whole AutoIT script goes haywire...

Ideally I want a way to force it to one or the other,

but optionally,

If I could find how to detect it pre script execution, I could construct the class

strings on the fly.

Apologies for the repetition but this continues to be a challenge for me.

Share this post


Link to post
Share on other sites



So when the first check fails, run the second. If both steps fail then execute your error.

Wouldn't that work?

Share this post


Link to post
Share on other sites

So when the first check fails, run the second. If both steps fail then execute your error.

Wouldn't that work?

I'm essentially wiring up a bunch of button clicks here. Ultimately there will be thousands

of them for my testing so I either want to force it to always be one value or set them

all to one or the other before I start.

Coding an error response for every possible button push/tab selection isn't very efficient.

Still looking how to extract the class name to parse out the control hex address or what

ever that last portion is.

Thanks!

Share this post


Link to post
Share on other sites

_CtrlGetByPos() didn't work?


Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.

Share this post


Link to post
Share on other sites

_CtrlGetByPos() didn't work?

That looked like a lot of overhead. I decided to investigate further and

this morning it looks like I found the solution.

Just Loping off the last part of the class string reported from Window Info appears to work:

ControlClick("GeoExpress","","[CLASS:WindowsForms10.BUTTON.app; TEXT:Encode Selected Jobs; INSTANCE:7]")

instead of

ControlClick("GeoExpress","","[CLASS:WindowsForms10.BUTTON.app.0.3ce0bb8; TEXT:Encode Selected Jobs; INSTANCE:7]")

Thanks for helping me work through this responders!

Share this post


Link to post
Share on other sites

That looked like a lot of overhead. I decided to investigate further and

this morning it looks like I found the solution.

Just Loping off the last part of the class string reported from Window Info appears to work:

ControlClick("GeoExpress","","[CLASS:WindowsForms10.BUTTON.app; TEXT:Encode Selected Jobs; INSTANCE:7]")

instead of

ControlClick("GeoExpress","","[CLASS:WindowsForms10.BUTTON.app.0.3ce0bb8; TEXT:Encode Selected Jobs; INSTANCE:7]")

Thanks for helping me work through this responders!

Well, an update is in order...

The technique outlined above only works for ControlClick events not ControlFocus and several others.

With help from a friend, I devised a way much like someone suggested in an earlier post.

$ControlHandle = ControlGetHandle("GeoExpress","","[CLASS:WindowsForms10.SysTabControl32.app.0.3ce0bb8; INSTANCE:1]")

; @error = 1 when the control 3ce0bb8 doesn't exist.

If @error = 1 Then

#include "GeoExpress6.1_Lib_5c39d4.au3"

Else

#include "GeoExpress6.1_Lib_3ce0bb8.au3"

EndIf

This is the best I could do so far. I am going to develop in the 3ce0bb8 include realm and

when I'm done, copy it and do a global search and replace for the other include file.

Thanks again.

Some additional notes -

The windows class is given a name in the form:

<windowsformsversion>.<windowstyle>.app<hexappdomainhash>

where <windowsformsversion> is the version of the library and is a fixed string WindowsForms10.

<windowstyle> is in the form of window.<hexstyle> where <hexstyle> is the style of the window (see Control.GetStyle()) in hex.

Finally, <hexappdomainhash> is the hash code of the current app domain given in hex.

Share this post


Link to post
Share on other sites

The "If/Then" statement with the #include's are redundant, both includes are included regardless.


Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.

Share this post


Link to post
Share on other sites

The "If/Then" statement with the #include's are redundant, both includes are included regardless.

Thwarted at every turn!

I guess I'll have to build the class string dynamically.

Thanks Again!

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