Wait for lclick before continuing script

[Aaron]

There is a time within my script when I need to pause the script and wait
for the user to click within the area of a button before continuing.
This is for input.

I'm capturing the screen then looking for the needle in the haystack with
an image of a button.

The problem is that I can't figure out how to tell the script that if the
user clicks anywhere within the button area then to continue.

Here is what I have so far.
The last line of code is where I need the help.
If you see other problems, please point them out.

Thank you in advance.




//----BEGIN CODE----->

LET>RX = 0 //RESOLUTION BOTTOM POSITION X OF SCREEN
LET>RY = 0 //RESOLUTION BOTTOM POSITION Y OF SCREEN
LET>N1LX = 0 //NEEDLE IMAGE1 TOP LEFT X POSITION
LET>N1LY = 0 //NEEDLE IMAGE1 TOP LEFT Y POSITION
LET>N1RX = 0 //NEEDLE IMAGE1 BOTTOM RIGHT X POSITION
LET>N1RY = 0 //NEEDLE IMAGE1 BOTTOM RIGHT Y POSITION


//Captures screen resolution & store in variables RX and RY

GetScreenRes>RX,RY

//----------->

//Captures Image of screen using vars RX and RY and save it -
//as screen_01.bmp

ScreenCapture>0,0,RX,RY,c:\screen_01.bmp

//----------->

//opens Needle_01.bmp and finds the TOP LEFT position within screen_01.bmp Then stores the TOP LEFT //position using variables N1LX,N1LY

FindImagePos>c:\Needle_01.bmp,c:\screen_01.bmp,20,0,N1LX,N1LY,imgs

//How do I write the last line of code to get the position of the bottom right?
//Finds the BOTTOM RIGHT position within Needle_01.bmp
//Then stores the BOTTOM RIGHT Position using variables N1RX,N1RY

FindImagePos>c:\Needle_01.bmp,c:\screen_01.bmp,20,?,N1RX,N1RY,imgs



//----Next Problem----->


//How do I then take the N1LX,N1LY and the N1RX,N1RY and do the //following.

wait>lClick,Anywhere within the N1LX,N1LY thru N1RX,N1RY rectangle area

//when lClick, script continues

[Aaron]

Thanks for the trial, now I know the support is not what they say it is.
I'll try some other software.

[Me_again]

Aaron,

MJTnet is a UK company, April 9th is a public holiday in the UK.

The forum is primarily for peer-to-peer support and may not always yield an instant response. If you have a critical support requirement use the form http://www.mjtnet.com/contact.htm to contact mjt directly.

[Aaron]

Sorry, I dint realize
Anyway, I could use some help.
I read through most of the manual, and the software seems to be a dream come true.
As I read more and more its just amazing what MS can do.
Anyway, I fixed the part with the array, I had Xpos,Ypos when trying to retrieve the vars. I changed them to Xpos_0,Ypos_0 and that worked fine. Then I fiddled with something and the vars dont seam to work now.

//----------I followed the video but wont work----------

Let>sX = 0
Let>sY = 0
Let>Xpos = 0
Let>Ypos = 0
GetScreenRes>sX,sY
ScreenCapture>0,0,sX,sY,c:\imgs\screen.bmp
SetFocus>Outlook Express
FindImagePos>C:\imgs\tools.bmp,C:\imgs\screen.bmp,10,1,Xpos,Ypos,imgs
if>imgs>0
MoveMouse>Xpos_0,Ypos_0
LClick
endif
wait>15
SetFocus>Outlook Express
CloseWindow>Outlook Express
//END TEST

[Marcus Tettmar]

Aaron,

Use the WaitKeyDown function to wait for a lclick:

WaitKeyDown>VK1

VK1 is the virtual key code for the left mouse button:

http://www.mjtnet.com/vkcodes.htm

[Aaron]

I did that! Works great.
Now I'm having trouble with the code above your comment,
The mouse wont even move to the Xpos,Ypos
It just sits there until the wait>15 when outlook is closed down.

I look at the video on image reconition several times and just cant see were the code is wrong

Thanks

[Marcus Tettmar]

Looking at your code that would suggest it fails to find the image. What is the value if imgs? Step through the code. Look at the watch list - does it find the image (if so imgs would be greater than zero - if not, it won't be able to click on it) are there any values for XPos_0 and YPos_0? Debug, step through with F8, or insert a diagnostic like:

MessageModal>imgs

Put that above the If statement. Debug, don't guess.

[Aaron]

Let>sX = 0
Let>sY = 0
Says 0 imgs but the images are there, I went to the file copied right from the title bar in explorer window and then pasted into the script. Not miss spelled and defiantly in the folder. This is my entire code, am I missing something? If you don't see anything, would you mind pasting it into your MS and testing it. must be something im over looking

thank you again


Let>Xpos = 0
Let>Ypos = 0
GetScreenRes>sX,sY
ScreenCapture>0,0,sX,sY,C:\imgs\screen.bmp
SetFocus>Outlook Express
FindImagePos>C:\imgs\tools.bmp,C:\imgs\screen.bmp,10,1,Xpos,Ypos,imgs
MessageModal>imgs
if>imgs>0
MoveMouse>Xpos_0,Ypos_0
LClick
endif
wait>15
SetFocus>Outlook Express
//CloseWindow>Outlook Express
//END TEST

[Aaron]

Let>sX = 0
Let>sY = 0
Let>Xpos = 0
Let>Ypos = 0
GetScreenRes>sX,sY
ScreenCapture>0,0,sX,sY,c:\imgs\screen.bmp
SetFocus>Outlook Express
FindImagePos>C:\imgs\tools.bmp,C:\imgs\screen.bmp,10,1,Xpos,Ypos,imgs
if>imgs>0
MoveMouse>Xpos_0,Ypos_0
LClick
endif
wait>15
SetFocus>Outlook Express
CloseWindow>Outlook Express
//END TEST

[Marcus Tettmar]

This code isn't going to work for me if I paste it into my copy of Macro Scheduler because it needs an image on your PC (c:\imgs\tools.bmp) and my screen looks different.

FindImagePos is *NOT* finding tools.bmp inside screen.bmp. As I am not sitting in front of your PC I will have to guess at the reason.

I notice that just after capturing the screen with screen.bmp you then SetFocus>Outlook Express. Now, if tools.bmp is an image taken from Outlook Express and assuming you are looking for something in Outlook Express, then if Outlook Express was not the active application when the ScreenCapture was taken then FindImagePos may not find tools.bmp. Perhaps you want to SetFocus>Outlook Express *before* the ScreenCapture.

Am I right? Is the image you are looking for on the screen part of Outlook Express? If so, make sure Outlook Express is active *before* the ScreenCapture command. If it is in the background, or some other application is in front of it when the ScreenCapture takes place then it won't find your image.

[Aaron]

SPELLING
MoveMouse>Xpos_0,Ypos_0
to
MouseMove>Xpos_0,Ypos_0

I also added a wait>5 after setfocus

Thank you for your time

Great program!!

[Marcus Tettmar]

Well done! I didn't spot the obvious spelling mistake!

[jpuziano]

Hi Marcus,

There is an enhancement idea in here. The Macro Scheduler Advanced Editor shows valid commands in green... so looking at Aaron's original code in the editor, MoveMouse> shows in black text because its not a valid command. The proper command, MouseMove>, would have shown in green text.

That shows the bad command but obviously, its not eye-catching enough to really pop out at you and alert you to the problem... but it could be.

In Macro Scheduler, all non-comment non-blank lines must start with a valid Command... yes? If so, why not have the Advanced Editor show any non-comment non-blank lines that *don't* start with a valid command... with blinking text.

Ordinarily I hate blinking text... however if its for a feature that's going to immediately point out a miss-spelled command and save me oodles of time in debugging... I'm going to love it instead.

What do you think? Could the color syntax highlighting code be enhanced to point out such errors?

[Marcus Tettmar]

Err, I didn't spot it because I was looking at the code in the forum. Had I done what was suggested and pasted it into Macro Scheduler I am sure I would have noticed immediately. Personally I really don't like the idea of blinking text and am not convinced it is necessary, but ...

[jpuziano]

Agreed, in most places I have seen blinking text used, I have found it annoying... however... here it would be the editor pointing out that my line of code has a serious problem; there should be a valid command there and there isn't one. I could get used to that.

There are other ways to point out the bad line of code besides blinking text. In Microsoft Word, it underlines the miss-spelled word with a squiggly red underline. If you can do that instead, it might serve the purpose as well.

I guess the point is, the editor could be helping by pointing out such errors. Yes, expert coders who know what colors to expect may have spotted the error as-is... but newbies will not.

A feature like this would help newbies spot their bad commands right away and even reduce support calls... and that's a good thing.

Food for thought... take care.