[Resolved]Having a problem accessing GUI objects NOT made by AutoIT

[everseeker]

OK, Have an application that displays a row of tabs. First 2 attachments show the windows info data when pointing at either of the first 2 tabs. As you can see, there is no difference that I can see (Except for ID... that number increments every time I click on any tab... it seems to be working like a "counter" of the number of times I click on tabs... can't use it)

The only thing that I can see is in visible text (last 2 enclosures) they show, as part of the visible text, the contents of the active tab only. I might be able to use that to confirm my tab was selected, but not to select the correct tab in the first place.

So, how do I "click" on the tabs (Without absolute positioning... This will go out to people with differing resolutions.. I don't want to have to futz with that nightmare

--------------

I DO have limited access to the developer. Does anyone have a change that the developer could implement, that would help me (without changing the control he uses...)

Edited March 25, 2008 by everseeker

[everseeker]

As a followup, Attached is a comparison of AutoIT's Window Info and Hp QTPro's Object Spy:

Is there any way to get AutoIT3 to access the data shown as swfname_path ??? (Buttons on the same page... same issue of nesting)

Edited March 21, 2008 by everseeker

[everseeker]

Lastly, I have a combobox that I want to work with... The only combo box controls I can fing in AutoIT <GuiComboBoxEx.au3>

appear to only work with AutoIt3 created Combo Boxes.......

[everseeker]

Thanks for ALL the wondurful help...

I have discovered ControlCommand..... looking into it

[FreeFry]

Your 'developer' might wanna have a look at the GuiTab Management UDF's in the helpfile to select the correct tab, there's probably other UDF's in there to help him select/whatever with the other controls in the window.

[PsaltyDS]

As a followup, Attached is a comparison of AutoIT's Window Info and Hp QTPro's Object Spy:

Is there any way to get AutoIT3 to access the data shown as swfname_path ??? (Buttons on the same page... same issue of nesting)

The "swf" implies Shockwave Flash windows, which are completely opaque to standard Windows APIs, and therefore to AutoIT.

[FreeFry]

O shii... then it's an all other ball game. :|

[everseeker]

The "swf" implies Shockwave Flash windows, which are completely opaque to standard Windows APIs, and therefore to AutoIT.

Actually, turns out that the SWF means that QuickTest pro is smoking de crack.....

FreeFry pretty much nailed it.... (actually, the Dev is still on his Island.... I am the one coding to his output)

[zfisherdrums]

Hello everseeker,

It appears youre working with a financial calculator of some kind. It also appears you're using QTPro for some in-house automation but are seeking to utilize AutoIt for distributed automation in the field? Are these assumptions correct?

I'm sure you know, but just to clarify for future trollers, that SWF stands for the System.Windows.Forms namespace that .NET apps use. Being that these Tab controls appear to be run of the mill tab controls ( as far as .NET is concerned ), have you thought about using .NET reflection to automate the form? Are there any alternate means of navigating the tab controls (ie, hotkeys )?

[everseeker]

Hello everseeker,

It appears youre working with a financial calculator of some kind. It also appears you're using QTPro for some in-house automation but are seeking to utilize AutoIt for distributed automation in the field? Are these assumptions correct?

I'm sure you know, but just to clarify for future trollers, that SWF stands for the System.Windows.Forms namespace that .NET apps use. Being that these Tab controls appear to be run of the mill tab controls ( as far as .NET is concerned ), have you thought about using .NET reflection to automate the form? Are there any alternate means of navigating the tab controls (ie, hotkeys )?

Cool!

1. It's a Healthcare thing

2. Exactly correct... need to "Bulk test" all rates from spreadsheets

3. I did not know that... System.Windows.Forms.... OK

4. NET reflection to automate the form... umm... huh?

5. nope, no hotkeys anywhere (That would be too easy!)

[everseeker]

Hello everseeker,

It appears youre working with a financial calculator of some kind. It also appears you're using QTPro for some in-house automation but are seeking to utilize AutoIt for distributed automation in the field? Are these assumptions correct?

I'm sure you know, but just to clarify for future trollers, that SWF stands for the System.Windows.Forms namespace that .NET apps use. Being that these Tab controls appear to be run of the mill tab controls ( as far as .NET is concerned ), have you thought about using .NET reflection to automate the form? Are there any alternate means of navigating the tab controls (ie, hotkeys )?

While I have you... here's my current dilema (Pretty much related to the others, but I think easier to understand)

I have a dropdown box (attached shows the box and Autoit Info)

I want to select the entry in this combobox that matches a variable ($MasterArray[$Counter][34])

I tried the following...

...........snip..........
  ConsoleWrite("Opening Choose Plans window. Plan ID: " & $MasterArray[$Counter][34] & @CRLF)
  ConsoleWrite(@error & @CRLF)
  ControlClick("Rate Calculator", "", "[CLASSNN:WindowsForms10.COMBOBOX.app.0.378734a8; INSTANCE:8]")
  ConsoleWrite(@error & @CRLF)
  $x = ControlCommand("Rate Calculator", "", "[CLASSNN:WindowsForms10.COMBOBOX.app.0.378734a8; INSTANCE:8]", "FindString", $MasterArray[$Counter][34])
  ConsoleWrite($x & " " & @error & @CRLF)
  ControlCommand("Rate Calculator", "", "[CLASSNN:WindowsForms10.COMBOBOX.app.0.378734a8; INSTANCE:8]", "SetCurrentSelection", $x)
  ConsoleWrite(@error & @CRLF)
  $CandidatePlan = ControlCommand("Rate Calculator", "", "[CLASSNN:WindowsForms10.COMBOBOX.app.0.378734a8; INSTANCE:8]", "GetCurrentSelection", "")
  ConsoleWrite(@error & @CRLF)
  $GettingOut = "False"
  Do
   ConsoleWrite("Candidate: " & $CandidatePlan & @CRLF)
   If $CandidatePlan = $MasterArray[$Counter][34] Then
    ConsoleWrite("They're equal... happy days" & @CRLF)
    $gettinout = "True"
    Sleep(1000)
    Send("{tab 3}")
    Sleep(1000)
   Else
    ConsoleWrite("They're not the same... Keep looking" & @CRLF)

    ...........snip..........

Here's the output:

Opening Choose Plans window. Plan ID: AUTOGRAPH Total / H$A
0
0
0 1
1
1
Candidate: 0
They're equal... happy days

The 1's indicate an error... but what?

and why is that compare (If $CandidatePlan = $MasterArray[$Counter][34] Then) evaluating to True????

[FreeFry]

Try checking the value of $CanditatePlan and $MasterArray when it evaluates to true.

And further that, I believe you're not supposed to use CLASSNN in combination with INSTANCE...

[everseeker]

Try checking the value of $CanditatePlan and $MasterArray when it evaluates to true.

And further that, I believe you're not supposed to use CLASSNN in combination with INSTANCE...

Well, changed the ConsoleWrite....Also killed the Instance references...

ConsoleWrite("Opening Choose Plans window. Plan ID: " & $MasterArray[$Counter][34] & @CRLF)
  ConsoleWrite("Error Code 1 is " & @error & @CRLF)
  ControlClick("Rate Calculator", "", "[CLASSNN:WindowsForms10.COMBOBOX.app.0.378734a8]")
  ConsoleWrite("Error Code 2 is " & @error & @CRLF)
  $x = ControlCommand("Rate Calculator", "", "[CLASSNN:WindowsForms10.COMBOBOX.app.0.378734a8]", "FindString", $MasterArray[$Counter][34])
  ConsoleWrite("Error Code 3 is " & @error & @CRLF)
  ConsoleWrite("Find location is " & $x & @CRLF)
  ControlCommand("Rate Calculator", "", "[CLASSNN:WindowsForms10.COMBOBOX.app.0.378734a8]", "SetCurrentSelection", $x)
  ConsoleWrite("Error Code 4 is " & @error & @CRLF)
  $CandidatePlan = ControlCommand("Rate Calculator", "", "[CLASSNN:WindowsForms10.COMBOBOX.app.0.378734a8]", "GetCurrentSelection", "")
  ConsoleWrite("Error Code 5 is " & @error & @CRLF)
  $GettingOut = "False"
  Do
   ConsoleWrite("Candidate: " & $CandidatePlan & @CRLF)
   If $CandidatePlan = $MasterArray[$Counter][34] Then
    ConsoleWrite($CandidatePlan & " is the same as " & $MasterArray[$Counter][34] & @CRLF)
    $gettinout = "True"
    Sleep(1000)
    Send("{tab 3}")
    Sleep(1000)
   Else
    ConsoleWrite("They're not the same... Keep looking" & @CRLF)

and here's the output...

Opening Choose Plans window. Plan ID: AUTOGRAPH Total / H$A
Error Code 1 is 0
Error Code 2 is 0
Error Code 3 is 1
Find location is 0
Error Code 4 is 1
Error Code 5 is 1
Candidate: 0
0 is the same as AUTOGRAPH Total / H$A

no change to the error reporting

(and the evaluation is plain baffeling.. it is Obviously False)

[everseeker]

Is there a bug in my implementation of the ControlCommand routine?

or is the ControlCommand routine problematical?

Edited March 24, 2008 by everseeker

[zfisherdrums]

$CandidatePlan is a number. $MasterArray[$Counter][34] is a string.

It appears that comparing that string to a zero value would return true; the string value has no inherent numerical value.

Dim $CandidatePlan = 0
Dim $MasterArray[1][35]
Dim $Counter = 0
$MasterArray[$Counter][34] = "AUTOGRAPH Total / H$A"

ConsoleWrite( $MasterArray[$Counter][34] & @CRLF)
ConsoleWrite( ( $CandidatePlan = $MasterArray[$Counter][34] ) & @CRLF)
ConsoleWrite( ( $CandidatePlan - 2 ) & @CRLF)
ConsoleWrite( ( $MasterArray[$Counter][34] - 2 ) & @CRLF)

Produces this:

AUTOGRAPH Total / H$A
True
-2
-2

Try enclosing the $CandidatePlan value in quotes.

Edited March 24, 2008 by zfisherdrums

[zfisherdrums]

Is there a bug in my implementation of the ControlCommand routine?

or is the ControlCommand routine problematical?

Try something like this, maybe?

#Include <GuiComboBox.au3>

ComboBox_SelectString( "Rate Calculator", "", _
    "[CLASSNN:WindowsForms10.COMBOBOX.app.0.378734a8]", $MasterArray[$Counter][34] )

Func ComboBox_SelectString( $winTitle, $winText, $control, $option )
    Local $hWnd = ControlGetHandle( $winTitle, $winText, $control )
    Local $index = _GUICtrlComboBox_FindString( $hWnd, $option )

    If $index = -1 then
        ConsoleWrite( $option & " not found"    & @CRLF)
        SetError( 1 )
        Return False
    EndIf

    If $index = 0 then
       ; If the item is the first in the list, use hotkeys to navigate to it
        ControlSend( $winTitle, $winText, $hWnd, "^{PGUP}" )
    Else
       ; Select the item right before the target index, then send down
        _GUICtrlComboBox_SetCurSel($hWnd, $index - 1)
        ControlSend( $winTitle, $winText, $hWnd, "{DOWN}" )
    EndIf
    
    Return True
EndFunc

I use keys to navigate to the target index because that will fire the SelectedIndexChanged event. In experiments I ran with a .NET form, I noticed that none of the ComboBox selection functions truly changed the selected index in such a way that it triggered this crucial event. Otherwise, we're just changing the appearance of the control but not affecting any changes in the business logic.

Edited March 24, 2008 by zfisherdrums

[FreeFry]

Change:

If $CandidatePlan = $MasterArray[$Counter][34] ThenoÝ÷ Ù:ºÚ"µÍYÝ[Ê ÌÍÐØ[Y]T[HH ÌÍÓXÝ^VÉÌÍÐÛÝ[VÌÍH[

That should fix the problem with the conditional executing at the wrong "times".

[everseeker]

Try something like this, maybe?

#Include <GuiComboBox.au3>

ComboBox_SelectString( "Rate Calculator", "", _
    "[CLASSNN:WindowsForms10.COMBOBOX.app.0.378734a8]", $MasterArray[$Counter][34] )

Func ComboBox_SelectString( $winTitle, $winText, $control, $option )
    Local $hWnd = ControlGetHandle( $winTitle, $winText, $control )
    Local $index = _GUICtrlComboBox_FindString( $hWnd, $option )

    If $index = -1 then
        ConsoleWrite( $option & " not found"    & @CRLF)
        SetError( 1 )
        Return False
    EndIf

    If $index = 0 then
      ; If the item is the first in the list, use hotkeys to navigate to it
        ControlSend( $winTitle, $winText, $hWnd, "^{PGUP}" )
    Else
      ; Select the item right before the target index, then send down
        _GUICtrlComboBox_SetCurSel($hWnd, $index - 1)
        ControlSend( $winTitle, $winText, $hWnd, "{DOWN}" )
    EndIf
    
    Return True
EndFunc

I use keys to navigate to the target index because that will fire the SelectedIndexChanged event. In experiments I ran with a .NET form, I noticed that none of the ComboBox selection functions truly changed the selected index in such a way that it triggered this crucial event. Otherwise, we're just changing the appearance of the control but not affecting any changes in the business logic.

That is perfect. Solved about 30 issues in 1 fell swoop!!! Thanks

(Since this issue has been resolved, I am deleting the Images to recover space)