Having trouble with AutoIt and Zoom Player

[BrewManNH]

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.

[timmy2]

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 June 7, 2013 by timmy2

[TheSaint]

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 June 7, 2013 by TheSaint

[timmy2]

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.

[TheSaint]

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 June 7, 2013 by TheSaint

[timmy2]

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)?

[TheSaint]

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 June 8, 2013 by TheSaint

[timmy2]

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 June 8, 2013 by timmy2

[TheSaint]

 

$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.

[timmy2]

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.

[TheSaint]

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 June 9, 2013 by TheSaint

[timmy2]

Just saying "thank you" again seems inadequate. I greatly appreciate your help and patience in this thread. Maybe it'll save someone else from frustration in the future.