Jump to content

Having trouble with AutoIt and Zoom Player


Go to solution Solved by timmy2,

Recommended Posts

Try using WinList with the class name as the title and then do an array display on the results, you should see how many windows have the same class name as the zoom player window. Do this with and without SystemInfo running and compare the differences.

If I posted any code, assume that code was written using the latest release version unless stated otherwise. Also, if it doesn't work on XP I can't help with that because I don't have access to XP, and I'm not going to.
Give a programmer the correct code and he can do his work for a day. Teach a programmer to debug and he can do his work for a lifetime - by Chirag Gude
How to ask questions the smart way!

I hereby grant any person the right to use any code I post, that I am the original author of, on the autoitscript.com forums, unless I've specifically stated otherwise in the code or the thread post. If you do use my code all I ask, as a courtesy, is to make note of where you got it from.

Back up and restore Windows user files _Array.au3 - Modified array functions that include support for 2D arrays.  -  ColorChooser - An add-on for SciTE that pops up a color dialog so you can select and paste a color code into a script.  -  Customizable Splashscreen GUI w/Progress Bar - Create a custom "splash screen" GUI with a progress bar and custom label.  -  _FileGetProperty - Retrieve the properties of a file  -  SciTE Toolbar - A toolbar demo for use with the SciTE editor  -  GUIRegisterMsg demo - Demo script to show how to use the Windows messages to interact with controls and your GUI.  -   Latin Square password generator

Link to post
Share on other sites

Thank you for the suggestion. I think the following message from SystemInfo's developer answers the question. Would you say that the lesson here is to always conduct a test for duplicate class names?  Do any tools already exist for this?

Also, I remain interested in TheSaints recommendation that using handles avoids the possibilty of duplication (and thus, I assume, the need to conduct a test for duplicate class names?). In my previous post I showed how relying on WinGetHandle("Zoom Player") to get Zoom Player's handle gave me the wrong handle. When I tried CLASS it was obviously conflicting with SystemInfo, so that approach was of no use.  What would have been a reliable method for determining Zoom Player's handle?

 

I can see the problem right away:
 
$handle2 = WinMove("[CLASS:TMainForm]","",0,0)
 
Our main window has the class name TMainForm. It looks like it is matching, and thus causing the issue.
 
I tell you what, I will have the guys change the class name and recompile in the morning. We should be able to pick something more unique so it does not cause a conflict for you.
Edited by timmy2
Link to post
Share on other sites

It shouldn't really be necessary for them to do that, as with a combination of handle and indexing instance, all should be sweet.

As you can see from the following example in the Help file, you can specify more than one element.

 

WinWaitActive("[TITLE:My Window; CLASS:My Class; INSTANCE:2]", "")

 

So something like the following, but get the correct Instance using the Windows Info Tool.

Once you get that, then only refer to the window for moves and such, by the $handle

Not forgetting that Mode can be important, and that a video title name, may be part of the Window title, which means the title could change if the video is changed.

$handle = WinGetHandle("[TITLE:Zoom Player; CLASS:TMainForm; INSTANCE:2]", "")
Edited by TheSaint

Make sure brain is in gear before opening mouth!
Remember, what is not said, can be just as important as what is said.

Spoiler

What is the Secret Key? Life is like a Donut

If I put effort into communication, I expect you to read properly & fully, or just not comment.
Ignoring those who try to divert conversation with irrelevancies.
If I'm intent on insulting you or being rude, I will be obvious, not ambiguous about it.
I'm only big and bad, to those who have an over-active imagination.

I may have the Artistic Liesense ;) to disagree with you. TheSaint's Toolbox (be advised many downloads are not working due to ISP screwup with my storage)

userbar.png

Link to post
Share on other sites

TheSaint, thank you very much for replying. 

Doesn't using more than one element imply a boolean AND between the elements? If so, I would have to know (or at least suspect) that the computer my script is running on has another program loaded whose CLASS or other element will conflict?

What I'm looking for now is an AutoIt programming approach that will prevent conflicts like what I've wrestled with this time -- if that's possible.

BrewManNH suggested using WinList to look for conflicts but is that a routine thing AutoIt experts do at the beginning of every script?

If indeed what you say is true -- that handles are the only element that can't be duplicated, I'm looking for a sure-fire method of determining the handle as early as possible so I can reference a window using its handle from then on in the script. As I pointed out in a recent post here, WinGetHandle("Zoom Player") yielded the wrong handle for no reason I can understand, but that's the only function I know of for determining the handle without actually trying to act upon the window (as WinMove, WinActivate, etc. do).  By the time I need to "act upon" a window it's too late to be crossing my fingers there are no conflicting windows. 

My experience and tests indicate that looking for an error after one of those "action" function is futile since throughout this ordeal rarely was an error generated; functions simply had to no effect.

So please understand, I think to get closure for this thread and really consider it "solved", it's important to find a method for avoiding similar situations in the future. Surely experts here have a policy or routine approach to programming scripts when they don't know the target environment and must avoid conflicts like what bit me.

Link to post
Share on other sites

That example was taken straight from the Help file, and as you can see, no boolean AND needed.

The adaption I posted should work, though you may need to change the Instance to '1' maybe.

With that code, there will be no conflict, unless you have two programs called Zoom Player and the same Instance .... extremely unlikely to say the least, so you can deem it a sure fire method for your purposes. In other words, it should be well and truly unique enough.

After the first WinGetHandle line, you should not need to refer to "Zoom Player' or Class or Instance again. Instead, you should be using that $handle in every other command that refers to the Zoom Player window and controls (individual Control classes aside).

If you still have issues, then play with the Instance in that WinGetHandle line.

Beyond that, then you are out of my depth of understanding.

EDIT

The 'System Info' program for instance, would more than likely require the following

$handle = WinGetHandle("[TITLE:System Info; CLASS:TMainForm; INSTANCE:1]", "")

where I'm sure you can see the textual difference.

If both it and Zoom Player were running at the same time, then the Instance number for the Class of TMainForm should be different as well.

Edited by TheSaint

Make sure brain is in gear before opening mouth!
Remember, what is not said, can be just as important as what is said.

Spoiler

What is the Secret Key? Life is like a Donut

If I put effort into communication, I expect you to read properly & fully, or just not comment.
Ignoring those who try to divert conversation with irrelevancies.
If I'm intent on insulting you or being rude, I will be obvious, not ambiguous about it.
I'm only big and bad, to those who have an over-active imagination.

I may have the Artistic Liesense ;) to disagree with you. TheSaint's Toolbox (be advised many downloads are not working due to ISP screwup with my storage)

userbar.png

Link to post
Share on other sites

That example was taken straight from the Help file, and as you can see, no boolean AND needed.

The adaption I posted should work, though you may need to change the Instance to '1' maybe.

With that code, there will be no conflict, unless you have two programs called Zoom Player and the same Instance .... extremely unlikely to say the least, so you can deem it a sure fire method for your purposes. In other words, it should be well and truly unique enough.

After the first WinGetHandle line, you should not need to refer to "Zoom Player' or Class or Instance again. Instead, you should be using that $handle in every other command that refers to the Zoom Player window and controls (individual Control classes aside).

If you still have issues, then play with the Instance in that WinGetHandle line.

Beyond that, then you are out of my depth of understanding.

EDIT

The 'System Info' program for instance, would more than likely require the following

where I'm sure you can see the textual difference.

If both it and Zoom Player were running at the same time, then the Instance number for the Class of TMainForm should be different as well.

 

Thank you for replying. I meant "AND" is implied, meaning all three conditions must be true: TITLE:System Info AND CLASS:TMainForm AND INSTANCE:1.  Please tell me if I'm misinterpreting the use of multiple identifiers.

So should I take it that you have no standard approach to finding the handle and avoiding conflicting windows?

Can you speculate why WinGetHandle("Zoom Player") yielded an invalid handle, whereas WinMove("[CLASS:TMainForm]") yielded the correct handle (but only once SystemInfo had been closed)?

Link to post
Share on other sites

Thank you for replying. I meant "AND" is implied, meaning all three conditions must be true: TITLE:System Info AND CLASS:TMainForm AND INSTANCE:1.  Please tell me if I'm misinterpreting the use of multiple identifiers.

So should I take it that you have no standard approach to finding the handle and avoiding conflicting windows?

Can you speculate why WinGetHandle("Zoom Player") yielded an invalid handle, whereas WinMove("[CLASS:TMainForm]") yielded the correct handle (but only once SystemInfo had been closed)?

It seems you are misunderstanding how it all works.

Not all those three conditions need to be true for it to work.

However, they do if you want to be guaranteed you are working with the correct Window and Control ... and that is the standard approach.

I can only speculate, that the TMainForm wasn't the Zoom Player one, or you were getting the handle for the Control only.

You need to be sure you are always working with the Zoom Player window, and any Control related to it. Calling a control on it's own, does not guarantee this.

You could in theory (and maybe reality) have many TMainForm controls running on your system at any one time.

If you are still having trouble understanding this, then play around with the Window Info Tool and various open Notepad windows until you do get it. You should see different Instances for the Edit control as the result.

NOTE

I can't confirm this on my current system (no AutoIt), but that's what my understanding and memory tell me.

EDIT

In your code, you refer to the control class on it's own, which you shouldn't be doing, as you have no guarantee you are working with the correct Window, and indeed, you haven't been at times. You require the correct Instance, but I believe the Title can help too.

Edited by TheSaint

Make sure brain is in gear before opening mouth!
Remember, what is not said, can be just as important as what is said.

Spoiler

What is the Secret Key? Life is like a Donut

If I put effort into communication, I expect you to read properly & fully, or just not comment.
Ignoring those who try to divert conversation with irrelevancies.
If I'm intent on insulting you or being rude, I will be obvious, not ambiguous about it.
I'm only big and bad, to those who have an over-active imagination.

I may have the Artistic Liesense ;) to disagree with you. TheSaint's Toolbox (be advised many downloads are not working due to ISP screwup with my storage)

userbar.png

Link to post
Share on other sites

Such a quick response. Wonderful!

And when I used your suggestion in some test scripts it does indeed help.

$handle = WinGetHandle("[TITLE:Zoom Player; CLASS:TMainForm]", "")   gets the correct handle for the ZP window, even with SystemInfo loaded (which has the same Class value).

$handle = WinGetHandle("[TITLE:Zoom Player]", "") gets the wrong handle for the ZP window.

$handle = WinGetHandle("[CLASS:TMainForm]", "") gets the wrong handle for the ZP window.

Wow... how can this be? I figured if the title is wrong and the class matches that of another program, there's nothing valid to latch onto and use. To quote one of ZP's developers:

Oh, of course - I didn't think of another window having the same class name! Another way to avoid it would be to be able to use Zoom Player's title in the WinMove function - but that fails for some reason. Though AU3Info shows the window title as "Zoom Player", this script shows it as "0":

Local $title = WinGetTitle("[TMainForm]", "")
MsgBox(0, "Full title read was:", $title)

I don't believe the Zoom Player window is a traditional program window - I'm wondering if that may be why it isn't working on the title? Though I don't understand why AU3Info shows what should be the correct title, and the script doesn't - I would have expected them both to have shown the same thing.

I wasn't alone in being confused by some of the results.

Regardless, your approach may be the "sure-fire" method I was seeking to guarantee that I'm referring to one specific window, even if there's another unknown program that uses the same Class name.

One last question, then:

At the end of your post you bring up something that I may not understand.

EDIT
In your code, you refer to the control class on it's own, which you shouldn't be doing, as you have no guarantee you are working with the correct Window, and indeed, you haven't been at times. You require the correct Instance, but I believe the Title can help too.

I didn't intentionally refer to "the control class"; I was focused solely on dealing with Windows - no controls or elements within a window. Real simple stuff, which is my current speed. Can you cite what code I used improperly to identify a window? This may be another great teaching moment.

Thank you again for the guidance.

EDIT: I don't know what's causing some of the text in the above quote boxes to be red but it's not intentional .

Edited by timmy2
Link to post
Share on other sites

 

$handle2 = WinMove("[CLASS:TMainForm]","",0,0)

You only mention the Class and not the Instance, for which we had two (at least) - Zoom Player and System Info.

From my understanding, TMainForm, is also a type of Control ... though that was probably poor wording on my part.

Make sure brain is in gear before opening mouth!
Remember, what is not said, can be just as important as what is said.

Spoiler

What is the Secret Key? Life is like a Donut

If I put effort into communication, I expect you to read properly & fully, or just not comment.
Ignoring those who try to divert conversation with irrelevancies.
If I'm intent on insulting you or being rude, I will be obvious, not ambiguous about it.
I'm only big and bad, to those who have an over-active imagination.

I may have the Artistic Liesense ;) to disagree with you. TheSaint's Toolbox (be advised many downloads are not working due to ISP screwup with my storage)

userbar.png

Link to post
Share on other sites

Sure, had I wanted to distinguish between the two programs, Zoom Player and SystemInfo, using the Instance value would've worked. But I didn't know SystemInfo was a factor any more than the many other resident tasktray programs. Therein lies the rub. 

BTW, how does one determine the Instance value of a window?  AutoIt Info Tool shows the Instance value of a Control but I see no mention of it in the Window section. Plus, I've opened two instances of Zoom Player, and AutoIt Info Tool shows the same Instance value of 1 for both, which I assume is because it's referring to a control instead of the window.

Nonetheless, I think you nailed it by suggesting I use two identifiers, Title and Class, to fetch the handle.  What's novel there is that either one alone yielded invalid info so -- somehow; only the presence of both worked.  BUT... (and this seem significant) in the days preceding my post I had been successfully using functions like WinActivate("Zoom Player"). Not to put too fine a point on it, but WinActivate("Zoom Player") worked for some functions like WinActivate, yet handle$=WinGetHandle("Zoom Player") yielded a bogus handle, YET... handle$=("[TITLE:Zoom Player;CLASS:TMainForm]") yielded the correct handle.

That sort of inconsistency is misleading and discomfiting.

Link to post
Share on other sites

I guess it is fair to say, that working with Window Titles can be a bit of a Dark Art.

Usually it is best to assume a conflict may occur, and so go the whole hog of using all you can to differentiate.

Most of the time though, I only use a Window Title, and it works fine every time ... except when it doesn't.

Some program Windows are impossible to work with, so every one that does work is a bonus in my view.

With your own GUI's of course, it's a non issue with the easily provided handle at creation time.

As for your question, I can only say, with the Info Tool, or else fail ... though you may be able to WinList all those of the same class and make a stab at the Instance ... if only one is present, then it's a safe bet it is '1', but then, you don't need it in that case.

As far as something like a Window Move goes, you could loop through a few instances if you check whether it moved successfully and it didn't.

Edited by TheSaint

Make sure brain is in gear before opening mouth!
Remember, what is not said, can be just as important as what is said.

Spoiler

What is the Secret Key? Life is like a Donut

If I put effort into communication, I expect you to read properly & fully, or just not comment.
Ignoring those who try to divert conversation with irrelevancies.
If I'm intent on insulting you or being rude, I will be obvious, not ambiguous about it.
I'm only big and bad, to those who have an over-active imagination.

I may have the Artistic Liesense ;) to disagree with you. TheSaint's Toolbox (be advised many downloads are not working due to ISP screwup with my storage)

userbar.png

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
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By timmy2
      Pasted below is a short, simple AutoIt script that I wrote to test TCP control of Zoom Player Max (ZP) . The functions available are at this link.
      May it help someone in the future.
      Thank you to BrewManNH and TheSaint for their help in other threads I started.
      ;simple AutoIt script for controlling Zoom Player via TCP HotKeySet("{ESC}", "Terminate") ;ESC to bail out ;these will be used when I open the TCP socket $ip = "127.0.0.1" $port = "4769" ;start TCP service TCPStartup() ;open TCP socket and see if it was successful $socket = TCPConnect( $ip, $port ) If $Socket = -1 Then MsgBox(4096,"Error","Failed to connect to ZP via TCP on localhost at port 4769.") Terminate() EndIf ;now loop, presenting Text Input prompt for user to enter a ZP function and optional parameters. while 1 ;text entry prompt with Cancel button $msg = InputBox("ZP TCP Controller","Enter text to send via TCP (default is play). Or Cancel to exit.): ", "5100 fnPlay" & @CRLF) if @error = 1 then Terminate() ;@CRLF needed at end of text to be sent! $msg = $msg & @CRLF ;the rubber meets the road here $send = TCPSend($socket, $msg) WEnd Terminate() Func Terminate() ;process ESC key and close TCP TCPCloseSocket($socket) TCPShutdown() Exit 0 EndFunc If anyone wants to add the ability to receive responses from Zoom Player I would welcome the addition.  Here's a link to a very clear explanation of communicating via TCP with ZP via Autohotkey, including receiving the info ZP sends back up the pipe.  Also, here's a link to download a neat TCP testing tool written in Delphi for the ZP community. Zoom Player is a great video player in my opinion, with inspiring depth AND incredible documentation.
       
×
×
  • Create New...