Jump to content

ControlGetFocus vs. au3Info


Recommended Posts

I'm stumped. I have been working on a script that I thought would be pretty straight forward. It's a practice script for me to learn more about the GUI features and just play around with seeing how different commands behave.

I'm using XNews as my test subject because I've written some small scripts for it to automate a few things. I figured I could put the small scripts together, add a GUI front end, and then play around with expanding on the stuff I'd written.

However, I've been banging my head against the wall because scripts that functioned as standalones with hotkeys suddenly wouldn't budge when I add them to this larger script with the GUI frontend. Something as simple as getting the program to Send an Up or Down keystroke to XNews wouldn't work.

I made sure the original scripts still worked which they did.

It wasn't until tonight that I figured what the problem was but I still haven't figured out if it's a problem or if I'm just not understanding what I'm looking at.

Anyway, here's the background....

There are 3 primary screens that I work with in XNews. Because most of the scripts I'd written before acted on just one of those screens I had not been too concerned about validating the control names that were being acted on because I'd wait to activate the hotkey until I actually got to the place I wanted the script to start up at.

When I started putting the scripts together I thought it would be a good idea to identify each of the Control Names for each of the windows and assign each of those to a global variable. Then, whatever function I ran, I could have the script do some validation using ControlGetFocus to make sure it was at the right place for what it was going to do.

I used Au3Info to get the ClassNameNN for each of the main screens. These are the results from au3Info for the 3 screens.

Main screen

Title: Xnews - [Newhosting]

Class: TXnewsFrame

Control ID: 1573242

ClassNameNN: TMyListView2

List Screen (messages)

Title: Xnews - [Newhosting :: alt.binaries.pictures.clip-art]

Class: TXnewsFrame

Control ID: 197062

ClassNameNN: TMyListView3

View Screen (individual message or picture)

Title: Xnews - [Newhosting :: alt.binaries.pictures.clip-art]

Class: TXnewsFrame

Control ID: 1312108

ClassNameNN: TOLEEdit1

I assigned those names to global variables.

Global $sMainControl

$sMainControl = "TMyListView2"

Global $sListControl

$sListControl = "TMyListView3"

Global $sViewControl

$sViewControl = "TOLEEdit1"

I added some code around each of the calling routines to check to make sure the correct control was being used.

Case $Button_04

$sControl = IDOpenControl()

If $sControl = $sListControl Then

Send("^{F9}")

EndIf

;-------------------------------------------------------------------------------

; Func IDOpenControl() HotKey = None

;-------------------------------------------------------------------------------

Func IDOpenControl()

Local $wintitle

$wintitle = "Xnews"

If Not WinActive($wintitle) Then

WinActivate($wintitle)

EndIf

$wintitle = WinGetTitle("")

If ControlGetFocus($wintitle) = $sMainControl Then

Return $sMainControl

EndIf

If ControlGetFocus($wintitle) = $sListControl Then

Return $sListControl

EndIf

If ControlGetFocus($wintitle) = $sViewControl Then

Return $sViewControl

EndIf

Return

EndFunc ;==>IDOpenControl

However, when I clicked on a control in the program to do something in XNews, nothing would happen. I thought at first I was losing focus on the XNews control because I wasn't getting anything returned or XNews would blink but then I wouldn't get any further response. So I wrote and rewrote code trying to find ways to make sure that the window and the control would stay in focus.

What I finally figured out was that the control name that was reported by ControlGetFocus was different then the one I was getting from Au3Info for the same control.

I'd get the following results from ControlGetFocus in the program

WinGetTitle = Xnews - [Newhosting :: alt.binaries.pictures.clip-art]

ControlGetFocus = TMyListView1 <<<------

and this from Au3Info

Title: Xnews - [Newhosting :: alt.binaries.pictures.clip-art]

ClassNameNN: TMyListView3 <<<-------

I ran a utility I'd written in AutoIt to "analyze" listview controls. The first thing it does is report the window title and active control name. It's results were the same as what I was getting in the current program. I checked XNews main control and it showed that its control name is the same as the XNews List control which makes sense since they both operate in the same manner. I can easily compenstate for this but my problem is why did Au3Info report different control names?

I can't get Au3Info to show me a TMyListView1 control anywhere and I haven't been able to find a TMyListView2 or TMyListView3 anywhere using AutoIt so I'm totally confused about where these Control names are coming from.

I've never had a situation that I'm aware of where ControlGetFocus and Au3Info didn't match on the names. If I did, I guess it didn't matter to the script that I was running.

If using the ControlID as the unique identifier for a control is the preferred method, what is the best way to validate that the user or the application is pointing to the correct Control if AutoIt doesn't have the ability to identify the ControlID?

Any enlightenment would be appreciated.

Thank you.

----

One other oddity related to this issue regarding Au3Info while I was using it on XNews.

When both the XNews main screen and the List screen are both visible, and the List window is not maximized, and I click on the XNews main screen so that it has the focus and the list window will move to the background. With XNews Main showing, and no other control showing, If I move Au3Info cursor over the XNews Main screen, the ClassNameNN TMyListView2 will appear **except** in the area that the List Window had been covering before the Main Window took the focus. Au3Info will report that region as TMyListView3.

I've tested this several times, closing both applications, and bringing them back up. The ControlID's change to match the respective Control names. When I maximized the List screen and started Au3Info and moved the cursor over it, Au3Info reported the control name as TOLEEdit1 except in the same area that the List window (now maximized) had been before.

Link to comment
Share on other sites

The fact that your application "does nothing" may or may not have anything to do with your questions or confusion over ClassNameNN. We could all get tied up in a discussion about that and still not get to the root of your problem.

Can you work to either 1) create a small piece of code that demonstrates your problem or 2) ask a specific question (or logical series of questions) ?? There are far too many variables here.

Dale

Free Internet Tools: DebugBar, AutoIt IE Builder, HTTP UDF, MODIV2, IE Developer Toolbar, IEDocMon, Fiddler, HTML Validator, WGet, curl

MSDN docs: InternetExplorer Object, Document Object, Overviews and Tutorials, DHTML Objects, DHTML Events, WinHttpRequest, XmlHttpRequest, Cross-Frame Scripting, Office object model

Automate input type=file (Related)

Alternative to _IECreateEmbedded? better: _IECreatePseudoEmbedded  Better Better?

IE.au3 issues with Vista - Workarounds

SciTe Debug mode - it's magic: #AutoIt3Wrapper_run_debug_mode=Y

Doesn't work needs to be ripped out of the troubleshooting lexicon. It means that what you tried did not produce the results you expected. It begs the questions 1) what did you try?, 2) what did you expect? and 3) what happened instead?

Reproducer: a small (the smallest?) piece of stand-alone code that demonstrates your trouble

Link to comment
Share on other sites

The fact that your application "does nothing" may or may not have anything to do with your questions or confusion over ClassNameNN.  We could all get tied up in a discussion about that and still not get to the root of your problem.

Can you work to either 1) create a small piece of code that demonstrates your problem or 2) ask a specific question (or logical series of questions) ??  There are far too many variables here.

Dale

<{POST_SNAPBACK}>

From your response, I'm not sure if you didn't read what I wrote all the way through or you didn't understand it. I'm going to assume you didn't understand and I'll just respond to the points you made above and see if I can clarify this for you.

1) I stated in the message that "What I finally figured out was that the control name that was reported by ControlGetFocus was different then the one I was getting from Au3Info for the same control." So, I think it actually does have something to do with my questions and that it does have to do with the ClassNameNN. I never stated that I was confused over ClassNameNN I said "I can't get Au3Info to show me a TMyListView1 control anywhere and I haven't been able to find a TMyListView2 or TMyListView3 anywhere using AutoIt so I'm totally confused about where these Control names are coming from." There's a difference.

2) Regarding your request for code, there is code in the message right after the phrase "I added some code around each of the calling routines to check to make sure the correct control was being used." and after the code I explain the problem and then the solution. Since I've already identified why it wasn't working I dont think adding anymore code would serve a purpose.

3) Specific question #1- "I can easily compenstate for this but my problem is why did Au3Info report different control names?" and specific question #2- "If using the ControlID as the unique identifier for a control is the preferred method, what is the best way to validate that the user or the application is pointing to the correct Control if AutoIt doesn't have the ability to identify the ControlID?"

Summary: There really aren't that many variables here. There's only one specific issue here that I've stated several times in the message which is "the control name that was reported by ControlGetFocus was different then the one I was getting from Au3Info for the same control." The rest of the material is background and information supporting the description of the problem. I've been working in the IT field for about 25 years and in my experience an anamoly like this usually isn't isolated to just one occurence. Since users are supposed to rely on Au3Info then I need to know if this is considered a problem or if it's just something that is normal and expected behavior for the application to do once in awhile. For now, until I can get an answer I'll find another method to validate the controls anytime I need to rely on a control name to perform a function.

Does that make it any clearer?

Link to comment
Share on other sites

Any tabs involved?

downloaded and tested... yes, tabs are a problem with Au3Info.exe. Never found a good way to use EnumChildWindows() api well with tabbed dialogs...

Lar.

<{POST_SNAPBACK}>

So, if there are multiple instances of a Window Class open, Au3Info ignores the classname and numbers all of the windows sequentially based on their handles.. and AutoIt numbers all of the windows as 1.

Which is why Au3Info reported ClassNames of TOLEEdit1, TMyListView2. TMYListView3... and AutoIT shows TOLEEdit1, TMyListView1, TMyListView1. I could always get a match on the TOLEEdit1 ClassName but never on the other two.

It's the little quirks that make programming so much fun :)

Thank you for clearing that up......

Link to comment
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
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...