r3dlined

I am running into more and more situations where I am not able to locally install/run my AutoIt scripts where it needs to interact with the application. Has anyone found a means to "screen scrape" for window text on a Remote Desktop session where window text cannot be pulled (since autoit is not locally installed)?

I'll see if I can reproduce and get the exact return of the window title. It's basically almost correct, what is returned, but there is garbage in it that makes the match fail.

No takers on this one?

Has anyone else had the issue of bad window titles being returned? I'll try to add some code here to help to see what I am doing. I have the current window title it is checking returned to see it and sometimes there is a lot of garbage added to the title. I find that restarting or rerunning the script helps, but not always. Func winCheck($winTitle, $winText = "", $exitOnFailure = 1, $winWaitActiveTimer = "default", $logError = 0) Opt("WinWaitDelay", 100) Opt("WinDetectHiddenText", 1) If $wintitle = "Program Manager" Then Opt("WinTitleMatchMode", 2) Else Opt("WinTitleMatchMode", 1) EndIf ;sets to true if exitOnFailure is true, but the active window is a message box. $isMsgBox = 0 ;if the timer has not been overriden it will setill be zero If $winWaitActiveTimer = "default" Then $winWaitActiveTimer = Lookup("Settings.WinWaitDuration") EndIf LogDebug("Starting window check on " & $winTitle & " " & $wintext) ;if the window exists check that it is active If Not WinWaitActive($winTitle, $winText, $winWaitActiveTimer) Then ;This means we tried to close down all windows in HBB and had a failure winCheck("Horizon Blood Bank - Program Manager") If StringInStr($wintitle, "Program Manager", 1) or StringInStr($wintitle, "Warning Code: RE28", 1) Then ;If $wintitle = "Horizon Blood Bank - Program Manager" Or $wintitle = "Warning Code: RE28" then LogTrace("Sending Fatal Error response") FullExit(Lookup("Response.FatalError")) EndIf ;reset the $wintitle so we only move the error box If WinActive("Error", "") Or WinActive("Warning", "") Or WinActive("Info", "") Or WinActive("Question","") Then LogDebug("Moving Error/Warning/Info window.") ;$errorTitle = WinGetTitle("[ACTIVE]") WinMove("[ACTIVE]", "", 0, 0) EndIf If $exitOnFailure Then LogError("Expected window failure. Expected " & $winTitle & " " & $wintext & ". Active window is " & WinGetTitle("[ACTIVE]")) killWindows() fullexit() Else If $logError Then LogError("Expected window failure. Expected " & $winTitle & " " & $wintext & ". Active window is " & WinGetTitle("[ACTIVE]")) SetError (-1) Return 0 EndIf EndIf LogDebug("Completed window check on " & $winTitle & " " & $wintext) Return 1 EndFunc ;==>winCheck

Anyone written scripts out there to do software validation?

I also want to note that as soon as I click on the screen the script stops hanging and my log picks up showing "Success of ControlFocus is: '1", but still sees Product Issue as the active window.

It actually looks like AutoIt is not accurately seeing the current active window (which is currently a warning message) by using WinGetTitle("[ACTIVE]"). The code right before the hang is: LogTrace("Starting ClickFormButton") LogDebug("Before ClickForm first winchek") winCheck($title, $text) LogDebug("Before ControlFocus") LogDebug("Active window is '" & WinGetTitle("[ACTIVE]")) $success = ControlFocus($title, $text, "[TEXT:" & $buttonText & "]") LogDebug("Success of ControlFocus is: '" & $success & "'") The last thing the log reads is " Active Window is 'Product Issue" which is actually false. The line "LogDebug("Success of ControlFocus is: '" & $success & "'")" is never called and the script is hanging at "$success = ControlFocus($title, $text, "[TEXT:" & $buttonText & "]")" In the screenshot you can see that Product Issue is not the active window at all (maybe this is just a glitch in the software itself).

I see to have an issue that when ControlFocus attempts to focus on a control that is not on the active window, the script will hang. This would be the case where right before ControlFocus is called, a warning message may have popped up. I would assume that this would cause ControlFocus to return 0, but it does not. The script will just hang there until I manually interact on the screen and clear the window. Any advise to get around this? Thanks,

Hi All, I am currently using AutoIt on a remote PC over remote desktop. I have turned off the clipboard feature on Remote Desktop (since I am copying and pasting text on the remote PC) and have discovered that minimizing the Remote Desktop session and screen savers kicking on will mess up the AutoIt execution. These have been avoided during testing. I am also using the latest version of AutoIt. I am trying to find out any tips or tricks you all have used to make AutoIt be a little more consistent. One area I keep seeing being in consistent is with both ControlClick and ControlFocus. These were used to click OK, CANCEL, QUERY, or some other button on a window. I have found that calling ControlFocus on the button and sending {SPACE} to be the more consistent of the two. I still see that the ControlFocus call will set focus to the button, but the {SPACE} call gets lost (the button doesn't actually get clicked). Also, when sending ALT commands to open the file menu on a window seems to not work sometimes as well. I have added sleep timers to wait after the window is active, but that didn't seem to help. I seems like the sendkeys just gets lost. I can post some specific code if needed. Thanks,

I am having a hard time in general with Autoit being a little inconsistent in it's performance. It seems a script will run fine a few times and then it will just fail to click a button. This certainly could be from the host machines software not being able to keep up, but I am still trying to nail it all down. One line that seems to work only some of the time is the following: ControlClick("Display Duplicate Patients", "", "[TEXT:OK]"). I have taken screenshots on this step failing and I can see the OK button is highlighted like it had been clicked, but the window did not close itself as it should have. Is it more consistent to use an actual mouse click? I'd like to stay away from that if possible since the buttons could move with another software generation. Thanks in advance for the help.

Taking a look at this would it be if the state is not 32 then it needs to be maximized somehow?>

So would getting the winstate be a bad method to find out if a window is minimized or not?

UGH!!!!! Shame on me for not reading the doc all the way through. Sorry about that and thank you.

getWinState() is returning 13 and I don't see that listed in the documentation. What is happening is that the window is minimized, winActivate is called on it, and the window seems to register as active and still minimized. I am even able to access that windows menu functions though it's minimized.

I am currently just sending CTRL-F4 to the application to close any child windows. The software does not like me doing that ONE bit! Is there a command to actually click the "X" in the upper right corner of a window to close it? It looks like the winclose winfunction just sends an CTRL-F4 command like I am already doing.