Problem with MouseMove... I think

tommystery · Post by **tommystery** » Fri May 16, 2008 12:45 pm

I'm currently trying out the demo of the program so I'm using the newest version.

I've written a script to recognize images and compare them with a bunch of if statements. The purpose of the program is to open different windows and click different parts of the screen. I've been running the program for about a week now and it has crashed for as second time now by what seems to have clicked the wrong spot on the screen. After the first time I added 1 second breaks between the window changing and I thoguht this would've fixed the problem. In any case; here is a sample of the script which executes this part of the program:

SetFocus> {windowname}
Wait>1
MouseMove>162,565
LClick
WaitWindowOpen> {windowname}
Wait>1
FindImagePos>C:\macrolive\submit.BMP,SCREEN,20,0,XPos,YPos,NumFound
MouseMove>XPos_0,YPos_0
LClick

As this works fine for a while and then seems to crash (after over 50 executions AND randomly) it seems like it's a problem with the program itself rather than the code. If anyone has experienced this problem and offer any help I'd greatly appreciate it - as if I'm going to purchase MacroScheduler I need a degree of stability.

Post by **Marcus Tettmar** » Fri May 16, 2008 1:32 pm

The first thing I see is that your code is not checking to see if FindImagePos actually found anything. If it didn't find a match then XPos_0, YPos_0 will not be a valid position. Similarly, if FindImagePos finds more than one match then the MouseMove will go to the first match. At the very least your code needs to be:

Code: Select all

FindImagePos>C:\macrolive\submit.BMP,SCREEN,20,0,XPos,YPos,NumFound
If>NumFound>0
  MouseMove>XPos_0,YPos_0
  LClick
Endif

Bear in mind that this will click on the first position returned if there is more than one match. So you may want an additional check or check that NumFound=1.

However, even if Macro Scheduler clicks somewhere other than you intend I would not expect a crash. Please enable logging and if the crash occurs again inspect the log file to determine where in the script the crash occurs, and make a note of any error message etc.

tommystery · Post by **tommystery** » Fri May 16, 2008 2:38 pm

Sorry, I think that my first post wasn't clear enough.

The program itself doesn't actually crash, the script will simply hang at waitwindowopen and everything from the program's side seems fine. I've kept a log every since the first crash and there is nothing abnormal with these executions which click in the wrong place.

The program actually clicks in the wrong place at 162,565; also having thought about this more and considering the window which has actually opened during these two false executions it seems like the program moves to the LClick command before the mouse finishes moving (is this possible?)

Prior to moving to the above co-ord. the mouse is supposed to rest at 0,0 - the window which was open this morning when the program hang is around (100 - 200),(450-500). Would adding a wait>1 before the LClick solve this problem?

I checked the log and the it went into the correct loop.

Post by **Marcus Tettmar** » Fri May 16, 2008 4:45 pm

I assume {windowname} is just a placeholder for the real window title? Any reason you need to obfuscate that here? It may help to see the real code.

larkspur · Post by **larkspur** » Fri May 16, 2008 8:03 pm

I don't know if this is of any help or not, but I put a Wait>0.1 before my LClicks after a MouseMove and that seems to make it more stable. In some cases, I use a longer Wait time if it needs it.

tommystery · Post by **tommystery** » Sat May 17, 2008 3:21 am

@ larkspur, so you've experienced this problem as well?

@mtettmar, the window names are actually derived from an application that I'm developing hence why the use of placeholders. It doesn't really matter as the GUI is simple Java; and the window which has opened on several occasions in this instance of the program is not coded to open ANYWHERE in the script. And as I said, the log shows that it hangs in the correct loop (as it's waiting for the window to open).

The most logical cause of this problem that I can think of is that the LClick is executed before the mouse finishes moving. I've added wait>1 (I didn't know that you could use 0.1) and we'll see how the script runs. I was just curious to know if this was a known problem so I could get a more definite answer.

armsys · Post by **armsys** » Sat May 17, 2008 3:49 am

Hi tommystery,
Whenever programming keyboard/mouse simulation, timing is alway your major concern becasue Macro Scheduler executes the keyboard/mouse simulation so fast that Windows often fails to catch. For example, in the worset scenario, the Windows is busy in indexing 200GB of folders and files and defragmenting 2 2TB hard drives simultaneously. Then, your script will definitively fail.

Rule of Thumbs:
1. Always set the right focus;
2. Always double check if it's exactly the window you're working (focusing) on. Don't rely on WaitWindowOpen>. The safest way is to use GetActiveWindow> to verify if the active (focused) window is exactly the one you want.
Just my 2 cents. Hope it helps.

tommystery · Post by **tommystery** » Sat May 17, 2008 2:28 pm

Thanks for the tip.

Do you think it would help to structure the script in this manner:

SetFocus>
GetActiveWindow>
MouseMove>
Wait>1
MouseMove>
Wait>1
LClick
Wait>1
SetFocus>
GetActiveWindow>
FindImagePos>
MouseMove>
Wait>1
MouseMove>
Wait>1
LClick

Or am I just wasting execution time? Considering the entire script, I need it to execute (in its entirety in <30s) {this is just a sample/part} but it also cannot fail under any circumstance. I figure that by inserting MouseMove twice I'm making sure that the mouse moves to the correct co-ordinates.

armsys · Post by **armsys** » Sat May 17, 2008 3:21 pm

Hi tommystery

Your script's robustness could be strengthened as follows:
For the purpose of demo, assume the window of interest is "Microsoft Word"
Let>WF_TYPE=2
SetFocus>Microsoft Word*
Label>Loop1
Wait>.2
GetActiveWindow>Win,x,y
If>{(pos("Microsoft Word",%Win%)=0)},Loop1
MouseMove>Pos_X,Pos_Y
LClick

Hope it helps.

tommystery · Post by **tommystery** » Sat May 17, 2008 8:15 pm

Thanks for the tip, that does seem like a cleaner way of doing it.

armsys · Post by **armsys** » Sat May 17, 2008 11:40 pm

Perhaps I misunderstood your problem.

tommystery · Post by **tommystery** » Sun May 18, 2008 3:00 am

Somewhat, I don't need to verify that the window is active but that the mouse is at the correct coordinates. But your script gave me the idea of using the GetCursorPos>X,Y to verify the cursor pos

Here is the revised script:
SetFocus> {Windowname}
Label>Loop1
Wait>.2
MouseMove>162,565
GetCursorPos>XC,YC
If>{(%XC%=162) AND (%YC%=565)},Loop1
Wait>.2
LClick
WaitWindowOpen> {Windowname2}
SetFocus> {Windowname2}
Wait>.2
FindImagePos>C:\macrolive\submit.BMP,SCREEN,20,0,XPos,YPos,NumFound
Label>Loop2
Wait>.2
MouseMove>XPos_0,YPos_0
GetCursorPos>XC,YC
If>{(%XC%=%XPos_0%) AND (%YC%=%YPos_0%)},Loop2
Wait>.2
LClick

Let me know what you think.

armsys · Post by **armsys** » Sun May 18, 2008 3:39 am

Thanks for sharing your progress with us.
In the absence of full knowledge of your pertinent (actual) app(s) and your full script, all my comments will fail you.
Whenever programming keyboard/mouse simulation, timing is your primary concern. Under such circumstance, GetActiveWindow is always your best insurance policy. BTW, mouse simulation is relatively more responsive than PRESS ALT, PRESS CTRL, PRESS SHIFT,....etc.
I'm sorry I can't see the benefit of using GetCursorPos> here. But ultimately you're your own judge as long as your script works as intended.
Good luck.

tommystery · Post by **tommystery** » Sun May 18, 2008 1:00 pm

The problem with my original script was that {somehow} out of over 100 executions, a button was pressed which is located above the intended one inside the intended window. I can only attribute this problem to having LClick execute before the mouse finishes moving to the intended coordinates.

Additionally, my windows are set up in such a manner that setting focus isn't all that important as there are never any windows which cover the control panel. I simply use setfocus> as additional insurance in case there is a popup of some sort which is not related to the application.

I apologize if I have caused any confusion.

tommystery · Post by **tommystery** » Mon May 19, 2008 2:12 am

Just want to add that after changing

If>{(%XC%=162) AND (%YC%=565)},Loop1

to

If>{(%XC%=162) OR (%YC%=565)},,Loop1

I had to modify the script to:

If>{(%XC%162) OR (%YC%565)}
Goto>Loop1
Endif

For it to execute properly