Having trouble with AutoIt and Zoom Player

[timmy2]

I had no problem controlling BS.Player Pro with an AutoIt script, but I could not get BSPP to jump to next chapter/bookmark in any video files so I've switched to Zoom Player Max.

Now I find that several of AutoIt's common window functions that were working fine previously do not work with ZPM.

For example, WinGetPos delivers totally invalid information about the ZPM window (ZPM is in F7 "video window only" mode, but then so was BSPP). WinClose fails to work. I try to use HWNDS (Handles) to refer to ZPM but no functions work properly if I use it. Even the Title fetched by WinGetTitle is useless in subsequent functions. About the only thing that works in this area is setting WinTitleMatchModet to 1 and referring to ZPM as "Zoom Player" in functions like WinWaitActive, etc.  Even then not all functions work with ZPM.

I really miss the ability to use WinGetPos to get info about ZPM's position and size, though -- that's a killer.

Do any readers here have experience controlling Zoom Player with AutoIt? ZPM has MANY settings so I'm hoping one of them is causing the incompatibility.

Thank you.

[guinness]

What is the Au3Info output? Probably the application doesn't use the Windows API for GUI creation. This isn't AutoIt's fault.

[timmy2]

What is the Au3Info output? Probably the application doesn't use the Windows API for GUI creation. This isn't AutoIt's fault.

 

Thank you for replying, guinness.  I'm not concerned with fault; I'd just like to use Autoit to control it.  The lead developer wrote me in their forum and said the following:

"It's possible it is not making the match because ZP uses unicode data fields for the window name."

 

 

I'm not learned enough in this subject area to determine if his comment is significant or not, much less if it addresses your comment. 

 

He also wrote:

"You can try to identify it by 'class', ZP uses "TMainForm" for the main window, for example:

WinWaitActive("[CLASS:TMainForm]", "")"

 

 

This reconciles with Au3Info's output:

>>>> Window <<<<

Title: Zoom Player

Class: TMainForm

Position: 1586, 1011

Size: 974, 549

Style: 0x96000000

ExStyle: 0x00010010

Handle: 0x0000000000040794

 

>>>> Control <<<<

Class: TImageBox

Instance: 1

ClassnameNN: TImageBox1

Name:

Advanced (Class): [CLASS:TImageBox; INSTANCE:1]

ID: 591928

Text:

Position: 0, 0

Size: 974, 548

ControlClick Coords: 417, 167

Style: 0x54000000

ExStyle: 0x00000000

Handle: 0x0000000000090838

 

>>>> Mouse <<<<

Position: 2003, 1178

Cursor ID: 0

Color: 0x3E3E3E

 

>>>> StatusBar <<<<

 

 

This much I DO understand, so I tried substituting "[CLASS:TMainForm]" for "Zoom Player" in functions like WinWaitActive and WinExists but this broke my script.

In the light of a new day I may be able to get by with identifying it using "Zoom Player", without having to change my code significantly, but I would like to know the underlying cause. 

Thank you again for replying.

[BrewManNH]

Playing around with Zoom Player and AutoIt, I didn't find any issues with identifying it's postion and didn't have any issues clicking the buttons on it.

 

 

ControlClick("[CLASS:TMainForm]", "", "[CLASS:TImageButton; INSTANCE:3]")
$aArray = WinGetPos("[CLASS:TMainForm]")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $aArray = ' & $aArray[0] & " - " & $aArray[1] & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
 

What this does is it clicks the equalizer button, and then prints to SciTE's console the X and Y position of the player window. Edited June 5, 2013 by BrewManNH

[timmy2]

Thank you VERY MUCH BrewManNH.

As I continued working with my script this morning I did indeed discover that using CLASS:TMainForm works in some functions, WinMov and WinGetPos thus far. However, it did not work for me in WinActivate, for example, which is one of the functions I first tried it with. (Now prove me wrong there and I'll really be deservedly ashamed.) 

I also greatly appreciate your unintended lesson in how to use SciTE's console for debugging! I've been using ToolTips for this so your example really helps. I should go back and work through all the tutorials and training available for AutoIT. Instead, as I did with the guitar as a kid, I dove in and am surely hampered by doing some things the wrong way.

---

I should probably add, for anyone who finds this thread in the future, that I'm running Zoom Player Max in "F7 mode", with the controller minimized. So the only thing visible is the video window. No chrome, no controls, no border, nada. This might impact how AutoIt's Functions work with Zoom Player.

Edited June 5, 2013 by timmy2

[BrewManNH]

Still not seeing the issue, I added WinActivate and WinActive to the mix with the class for the title and it's working for me (even in F7 mode).

ControlClick("[CLASS:TMainForm]", "", "[CLASS:TImageButton; INSTANCE:3]")
$aArray = WinGetPos("[CLASS:TMainForm]")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $aArray = ' & $aArray[0] & " - " & $aArray[1] & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
Sleep(2000) ; used to show that the above commands aren't making the window active by themself, the winactivate is bringing it into focus
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : WinActivate("[CLASS:TMainForm]") = ' & WinActivate("[CLASS:TMainForm]") & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : Winactive("[CLASS:TMainForm]") = ' & WinActive("[CLASS:TMainForm]") & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

[timmy2]

Hair being pulled and will now compare to my code. In the meantime, can you tell me why the code in the first example below runs without errors while the code in the second example below throws an error?

(Example that works)

ShellExecute("dot loop.m4v")

WinActivate("[CLASS:TMainForm]")
WinWaitActive("[CLASS:TMainForm]")
send ("p")

ControlClick("[CLASS:TMainForm]", "", "[CLASS:TImageButton; INSTANCE:3]")
$aArray = WinGetPos("[CLASS:TMainForm]")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $aArray = ' & $aArray[0] & " - " & $aArray[1] & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
Sleep(2000) ; used to show that the above commands aren't making the window active by themself, the winactivate is bringing it into focus
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : WinActivate("[CLASS:TMainForm]") = ' & WinActivate("[CLASS:TMainForm]") & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : Winactive("[CLASS:TMainForm]") = ' & WinActive("[CLASS:TMainForm]") & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

(Example that when run in SciTE generates a "==> Subscript used with non-Array variable.:" error)

ControlClick("[CLASS:TMainForm]", "", "[CLASS:TImageButton; INSTANCE:3]")
$aArray = WinGetPos("[CLASS:TMainForm]")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $aArray = ' & $aArray[0] & " - " & $aArray[1] & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
Sleep(2000) ; used to show that the above commands aren't making the window active by themself, the winactivate is bringing it into focus
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : WinActivate("[CLASS:TMainForm]") = ' & WinActivate("[CLASS:TMainForm]") & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : Winactive("[CLASS:TMainForm]") = ' & WinActive("[CLASS:TMainForm]") & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console


ShellExecute("dot loop.m4v")

WinActivate("[CLASS:TMainForm]")
WinWaitActive("[CLASS:TMainForm]")
send ("p")

[BrewManNH]

I can only assume it can't find the window so $aArray isn't an array.

[timmy2]

Thank you for your patient guidance in this matter, BrewManNH.  As to why "[CLASS:TMainForm]" didn't work earlier for me -- but does now -- I cannot explain it. I'm using it the same way as I did earlier.  This makes me wonder if running a script in SciTE repeatedly, modifying it between runs, can yield misleading results. 

[TheSaint]

I haven't looked closely at any of the above, but some of your earlier problems could be related to an active folder name that matches your Zoom Player one. It could have been causing recognition issues or delays. Just a thought anyway, that I've experienced on occasion, though using handles and classes should help avoid that.

[timmy2]

 

Still not seeing the issue, I added WinActivate and WinActive to the mix with the class for the title and it's working for me (even in F7 mode).

ControlClick("[CLASS:TMainForm]", "", "[CLASS:TImageButton; INSTANCE:3]")
$aArray = WinGetPos("[CLASS:TMainForm]")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $aArray = ' & $aArray[0] & " - " & $aArray[1] & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
Sleep(2000) ; used to show that the above commands aren't making the window active by themself, the winactivate is bringing it into focus
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : WinActivate("[CLASS:TMainForm]") = ' & WinActivate("[CLASS:TMainForm]") & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : Winactive("[CLASS:TMainForm]") = ' & WinActive("[CLASS:TMainForm]") & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

 

This like herding cats.

What worked earlier is now not working. I had WinMove working with CLASS:TMainForm earlier today but now it's stopped working, even after exiting and rebooting Windows 7.  I realize BrewManNH did not try WinMove above but I did, and it worked. For a while. Seriously. WinMove("Zoom Player") never worked so I had given up on it, but after BrewManNH suggested that WinActivate actually did work I tried the CLASS identifier in WinMove again and it worked.

Here's a stripped down version and WinMove does not move the video window, at least not on my PC. Someone please try it. Thank you.

;Zoom Player is default player for m4v filetype
;to test this elsewhere you'll need a 16x9 video file.

;load movie in Zoom Player
ShellExecute("dot loop.m4v")

;ensure that ZP is active
WinWaitActive("[CLASS:TMainForm]")

;send Play keystroke
Send("p")

WinMove("[CLASS:TMainForm]","",@DesktopWidth - 960,@DesktopHeight - 540,960,540)

Exit

[TheSaint]

Personally, I'd add in a timeout and If WinActive (though not strictly necessary) and some sleeps to make sure of timing being under control.

Conditional checks and sleeps allow you to test things far more easily.

[timmy2]

Thank you for replying, TheSaint. I have tried your suggestions and the results do not change.

The WinMove function, whether with Handle, Title or Class as an identifier, originally did not work for me. That's why I started this thread.  But after BrewManNH replied that some other Functions could use the Class identifier I figured I'd try it again.

It worked!  Using WinMove("[CLASS...) I had the ZP window moving to where ever I wanted it on the screen. Then, late today, it stopped working. In one of my previous replies to BrewManNH I mentioned my suspicion that the code can remain the same but the results seem unpredictable. I thought this might be the result of repeatedly running a script within SciTE, with modifications in between runs -- like maybe SciTE's environment can get corrupted, so that's why I rebooted.  Since rebooting didn't solve it I'm back to thinking this is either the work of Fortuna or a fundamental incompatibility between Zoom Player and AutoIt.

Also, after learning some debugging skilz from BrewManNH, I've discovered that in this situation the Functions will NOT generate an error when failing to work.  Simply testing for errors can be misleading.

[TheSaint]

Does the Window title change perhaps, after you send the 'P', which I presume is Play?

Does the 'P' need to be sent before the Window move?

Have you tried extended sleeps between sending 'P' and the moving of window, like 10 seconds or so?

[timmy2]

Window title does not change.

I've tried winmove before playing the video. No change in behavior.

Have tried extended sleeps.

Have made the window active, then tried ACTIVE, TITLE, CLASS, and "Zoom Player" in WinMove to no avail.

Here's a strange behavior of WinGetPos.

 

In the "Quote" below is some additional code I added to my simple test script.

 

Local $dw = @DesktopWidth
Local $dh = @DesktopHeight
Local $vx = $dw - 960
Local $vy = $dh - 540
Local $tx = $dw - 10
Local $ty = $dh - 10
 
;load movie in Zoom Player
ShellExecute("dot loop.m4v")
 
sleep(1000)
 
WinMove("[CLASS:TMainForm]","",$vx,$vy,960,540)
 
$vstats = WinGetPos("[CLASS:TMainForm]")
Talk("Active window stats (x,y,width,height):" & $vstats[0] & ", " & $vstats[1] & ", " & $vstats[2] & ", " & $vstats[3]) ;a Function that uses MsgBox.

WinGetPos always reports:

 

(x, y, width, height): 1600, 1060, 960, 540

 

These are the correct results given the variables I provided at the top and my desktop size. The only problem is that in reality ZP remains a much smaller window elsewhere on the screen, totally unphased by WinMove. 

 

I think ZP has a phantom window   that AutoIt is happily controlling, with no errors to report. 

 

--- 

 

Last note:  Zoom Player lead developer suggested I try their beta version. I installed it. WinMove worked once. From then on I get the same failed results.

Edited June 6, 2013 by timmy2

[BrewManNH]

I'm testing this with the free version of zoom player, and I'm not seeing any issues with moving and resizing the window. It works fine for me.

[timmy2]

I'm testing this with the free version of zoom player, and I'm not seeing any issues with moving and resizing the window. It works fine for me.

 

Thank you for the additional effort. I think it's significant that I installed the beta version and winmove worked. I probably didn't run the script more than once because I ran down the street screaming in celebration.  That joy was short-lived, though, because upon return I ran my script again and winmove didn't work. It's like something's getting corrupted that even rebooting won't fix.

Admittedly, I have not tried the free version. I definitely will.

I wonder if you had the same settings in ZP as I do? Did you leave everything at the default settings? If so, that should be easy to duplicate in a virtual machine or other computer here.

Earlier today, before trying the beta, I did install Zoom Player Max on another PC -- a Windows 7 box, activated it using my license file, and then ran the compiled version of my script on that machine. Same problems.  So that's two different machines on which winmove fails with Zoom Player Max here.

So there's a delta somewhere. Could you send me your script?   Did you let the ZP "Install Center" install all codecs?  Is your renderer EVR? What filetype is the video you tested it with?

Meanwhile, I will set up a clean test with the free version.

Thank you again!

Edited June 6, 2013 by timmy2

[timmy2]

BrewManNH's report that the free version worked with WinMove led me to trying my script on another couple of computers. I got the same results on all of them.  Then, in one that's a virtual machine running XP I started disabling tasktray items. I exited several at once, tried my script and WinMove worked!  I switched back to my production PC and started exiting them one at a time, testing my script after each change. Lo and behold, a program from Intelliadmin called SystemInfo.exe seems to be the cause of all my problems. I may be wrong, and I've written its author, but after numerous tests I can get my script to work perfectly with Zoom Player, winmove et al, by simply exiting SystemInfo.exe.

Maybe its author will confirm this but is it possible that if SystemInfo was written using AutoIt, it could conflict with other scripts running on the same PC? (One contradictory bit of evidence is that I had no problem using AutoIt to control BS.Player, and SystemInfo was running on my PC then, too.)

 

Thank you to both TheSaint and BrewManNH for their patient help. I'll mark this thread "solved" after I hear from Systeminfo's author and (hopefully) see that I've really isolated the cause.

[TheSaint]

This may illustrate why you would be better working with a handle for Window title, as it is possible that System Info program may have the same class name ... at least for the part of your code where you activate the program window of Zoom Player.

It may even be, that Zoom Player and System Info are written in the same language.

[timmy2]

This may illustrate why you would be better working with a handle for Window title, as it is possible that System Info program may have the same class name ... at least for the part of your code where you activate the program window of Zoom Player.

It may even be, that Zoom Player and System Info are written in the same language.

 

Insightful comment, TheSaint.  I had tried using the Handle identifier with Zoom Player but couldn't get it to work reliably (though in retrospect this could've been SystemInfo (which the author says is written in Delphi).

Perhaps you can help explain the results of the following test code I wrote in reaction to your comments above.

Opt("WinTitleMatchMode", 1)

$handle = WinGetHandle("Zoom Player")
If @error Then MsgBox(4096, "Error", "Could not find the correct window")
MsgBox(1,"","The handle is: " & String($handle))
$handle2 = WinMove("[CLASS:TMainForm]","",0,0)
If @error Then MsgBox(4096, "Error", "Could not find the correct window")
MsgBox(1,"","The handle is: " & String($handle2) & " or is it: " & string($handle))
WinMove($handle2,"",1600,1060)
If @error Then MsgBox(4096, "Error", "Could not find the correct window")

No errors are generated.  And the video window moves as each WinMove function instructs. The first MsgBox that shows the $handle from WinGetHandle says the handle is 0x004002D6. The second MsgBox that compares $handle with $handle2 says: "The handle is: 0x00070CDE or is it: 0x004002D6"

According to Au3Info the 070CDE value is the correct Handle.  The fact that I had been using WinGetHandle to get the handle value explains why subsequent uses of it failed to work. So what's another way for me to have gotten the handle before I tried a WinMove?

And, incidentally, I tried this code with SystemInfo running and not running. My script moved the video window twice when SystemInfo was not running; my script could not move the window in either instance of WinMove when SystemInfo was running, which suggests to me that regardless of having the handle as an identifier, SystemInfo is doing something else to impact my script.

Thank you VERY much for your help!