Get Control & Windows (AGAIN)

[paperguy]

So I checked through the forum and most of the issues with ME's Get Control and Windows windows seem to be that the windows aren't all constructed to a standard that would allow Get Control to be a 100% reliable.

 

My issue is a little different. I manually do the alterations to a file in my program and then replicate those actions with appropriate scripting in the ME editor. I do it a section at a time and fine tune as I go along till everything works. So thats what I did to convert my Adobe Illustrator files in FLASH to .swf files. First test run through went great. Later that evening fired up the computer and initiated my macro and it hung early into the script on a Get Control. I got the control did not appear error message which I thought was strange as I was looking right at it.

Went into the code and double checked everything and couldn't see anything wrong. So I thought well I'll just try it again - maybe I missed something as the macro was executing. Start the macro and everything worked! Odd. But then I remembered the first time when I was writing the macro, I stepped through the program myself and clicked the NO choice in the control window.

So playing my hunch I shutdown FLASH, restarted it and ran the macro and again the control was not found. But restarting the macro again and now it could see the control. So for some reason when FLASH starts the 1st time the macro doesn't see? - the control box. But CANCEL'ling the control box manually and restarting it, ME sees the control box.

My solution for the 1st time issue was to create an IF statement and if the control process failed the ELSE statement types in a N for NO into the control box and the macro runs properly.

 

If Control %C1% Visible
 Set Focus to %C1%
 Mouse Single Left Click on Control %C1%
Else
 Text Type: n
End If

 

Is there a better way to code for this event and why wouldn't ME see the control box the 1st time even though that box has focus, because typing in the N causes the control box to close?

[kunkel321]

I think your question might be a bit over my head (especially since I'm unfamiliar with Illustrator or FLASH) but I thought I'd throw out some thoughts....

As you've said, not all controls can be read by ME. (At work our main database is FileMakerPro which runs in a JavaRun time and the controls are invisible to ME -- very annoying!) I believe that if ME *can* see the control when you're building the macro, then it should *always* be able to see it. THat is, the control won't assume properties at runtime that will make it invisible to ME. (you gurus please correct me if this is wrong!). THerefore your problem is caused by something other than a control problem--per se. Iv'e had similar things happen and been able to remedy it with "wait fors" and and "delays."

 

For example: (I'm assuming that the control you're talking about is a pop up dialog that the FLASH application needs the user to respond too.) Note the window title of the dialog, and have:

1. Do the text manipulations that you already have

2. Then do a "Wait for Text" command (this will cause ME to wait until the keyque is done before it does anything else.)

3. Then "Wait for Window Title to be Active."

4. Then "Delay 250 milliseconds.

5. Then "If Control C1 Visible."

and so on ...

 

Is it possible that when you're running the macro, somehow the FLASH application is shut down or dormant? THen you execute the macro, but it gets to the "IF Control," but the app is still loading, so then you get an error message? I think this is not the case because you said you 1. shut down FLASH, 2. restarted FLASH, 3. The macro errored. However this *would* explain why the macro would work the second time it's run, but not the first....

 

Other thoughts...

-ME has a variety of "Launch Program" commands. Consider a 'Launch FLASH' command at the beginning of the macro.

 

-The workaround I use for FileMakerPro is to just do a 'move mouse' and 'mouse click' on the screen (relative to active window) instead of finding the control. THis works on standard dialogs if the message on the dialog is static (and hence the size/shape of the dialog doesn't change). I find that (assuming I have the timing down) it is very reliable. Windows are much easier to work with then controls.

 

-Maybe a loop...

1. You text manipulations.

2. Loop until T1<>T1.

3. If Control C1 Active

THEN

Click C1

Break from loop.

4. Loop.

and so on....

 

 

 

-steve

[paperguy]

I think your question might be a bit over my head (especially since I'm unfamiliar with Illustrator or FLASH) but I thought I'd throw out some thoughts....

Glad to have them, thank you, and it is a GUI so your experience should still be valid.

 

For example: (I'm assuming that the control you're talking about is a pop up dialog that the FLASH application needs the user to respond too.) Note the window title of the dialog, and have:

1. Do the text manipulations that you already have

2. Then do a "Wait for Text" command (this will cause ME to wait until the keyque is done before it does anything else.)

3. Then "Wait for Window Title to be Active."

4. Then "Delay 250 milliseconds.

5. Then "If Control C1 Visible."

The "Wait for Text" might be handy, but the "Wait for Window Title to be Active." would fail as the 1st time FLASH is run the control, nor the window title is not seen? properly by ME and after the wait period the macro aborts.

 

Is it possible that when you're running the macro, somehow the FLASH application is shut down or dormant? THen you execute the macro, but it gets to the "IF Control," but the app is still loading, so then you get an error message? I think this is not the case because you said you 1. shut down FLASH, 2. restarted FLASH, 3. The macro errored. However this *would* explain why the macro would work the second time it's run, but not the first....

To reiterate for clarity's sake, preventing failure of the macro occurs by:

• FLASH is running and I have to go the through a sequence that brings up the popup box manually by hand, then subsequent runs of the macro are successful
  
• FLASH is running and I have ran the macro 1st time with failure, then 2nd and subsequent runs are successful.
  

 

-The workaround I use for FileMakerPro is to just do a 'move mouse' and 'mouse click' on the screen (relative to active window) instead of finding the control. THis works on standard dialogs if the message on the dialog is static (and hence the size/shape of the dialog doesn't change). I find that (assuming I have the timing down) it is very reliable. Windows are much easier to work with then controls.

I originally had used the mouse move technique but lately have become enthralled with Get Control

 

-Maybe a loop...

1. You text manipulations.

2. Loop until T1<>T1.

3. If Control C1 Active

THEN

Click C1

Break from loop.

4. Loop.

and so on....

But if it never sees C1, wouldn't this be an infinite loop?

 

Getting back to the mouse click idea, I found it strange that although the popup window is not "seen" by Get Control it still must be active and in focus as by typing N

for "NO"clicks the right option button. One issue that I have with Flash is that depending where in the apps window your mouse cursor was located, popup boxes will appear in a few different places rather than in centre of the app window. Is there a mouse command in ME that can replicate the windows behaviour of "Snapping to default option"?. This is a mouse setting in windows and it will snap the mouse pointer to the default option of a windows dialog box in my case the "YES" option of my particular box, not the one I want but than a "relative offset" mouse move command would get me to the "NO" button to click. This might be advantageous to using absolute X,Y points.

 

Thanks for the help Steve

[kunkel321]

To reiterate for clarity's sake, preventing failure of the macro occurs by:

• FLASH is running and I have to go the through a sequence that brings up the popup box manually by hand, then subsequent runs of the macro are successful
  
• FLASH is running and I have ran the macro 1st time with failure, then 2nd and subsequent runs are successful.
  

 

But if it never sees C1, wouldn't this be an infinite loop?

 

My thought with the loop is that if the macro will reliably work on the second time through, then some action (or sequence of actions) must occur the first time through that makes it so the macro can 'see' it. If this action (or sequence) is inside the loop, then maybe the macro would fail the first time through the loop, but would work the second time through(??) This may well be an incorrect assumption though...

 

 

I originally had used the mouse move technique but lately have become enthralled with Get Control

 

Is there a mouse command in ME that can replicate the windows behaviour of "Snapping to default option"?.

 

Hmmm... Surely one of the If Control commands is the ME equivalent to this..

 

I've used the "Snap to..." Windows option in the past. As I recall the control that is "active" in this sense, can also by chosen/clicked by simply pressing the <Enter> key. Also don't forget the you can <Tab> <Tab> <Tab> through most Windows forms, then <Enter> to select the desired control....

 

Have to run off to work. Good luck!

[patrickbarrett]

From my experience with Controls and different programs, I'm guessing that the Control is actually changing. The only way to verify is to open the program and do a GetControl and note the Control Details. Then run the macro (which from the sounds of it, will fail) and then do what you've normally been doing. Go in and do another GetControl and I'm willing to bet that one of the Indexes changed in the Control Details.

 

For example, the first might be 8 5 1 1 4 4 and the second might be 8 5 2 1 4 4. It's easy to over look. I believe this to be because of cached forms, indexes and such (all depends on the program I guess).

 

I've run in to this on multiple applications, where it works one time, but not another. That's how I found this little change... I've found that the 2nd or 3rd Index (checking via the "Display Control Info") will either be a 1, 2 or 3 (again, depends on the program), so sometimes it works and others it doesn't if you're just using the one GetControl.

 

To get around this I will create the first GetControl. Every time it errors out, stop doing everything and go in to the Macro and duplicated the GetControl line. Then re-capture the new/different Control in this duplicated GetControl. At this point add in an "If NOT Control Enabled" and "End If", so the order would be (this can be done over and over if it fails on occasion):

 

Get Control C1 (1)

If NOT Control C1 Enabled

Get Control C1 (2)

End If

If NOT Control C1 Enabled

Get Control C1 (3)

End If

If NOT Control C1 Enabled

Get Control C1 (etc...)

End If

 

Note, if you find the pattern the program you are working with uses, you can just duplicate the GetControl lines and then go in to the direct editor and edit the Index that seems to be changing.

 

<GETCONTROL2P:01:WJVIEW.EXE:WFC.Window.8 - Default Work Order 005:5 WFC.Window.8 1 WFC.Window.8 1 WFC.Window.8 41 WFC.Window.8 1 WFC.EDIT >

 

<IFCONTROL:06:01>

<GETCONTROL2P:01:WJVIEW.EXE:WFC.Window.8 - Default Work Order 005:5 WFC.Window.8 2 WFC.Window.8 1 WFC.Window.8 41 WFC.Window.8 1 WFC.EDIT >

<ENDIF>

 

<IFCONTROL:06:01>

<GETCONTROL2P:01:WJVIEW.EXE:WFC.Window.8 - Default Work Order 005:5 WFC.Window.8 3 WFC.Window.8 1 WFC.Window.8 41 WFC.Window.8 1 WFC.EDIT >

<ENDIF>

 

I've used this method for 5 or 6 different programs and I no longer have issues with it not finding the controls "some times" and it working fine the rest.

 

Hope that helps!