response to users' input

[redsolar]

I have a sample task as below running in a Terminal Emulator

send>1
press enter
send>c
press enter
press enter
press enter
....
Since the response time for each command is different, I added the wait> command between each command to make sure that each command starts to execute right after the preivous one finishes execution. But, with the many wait commands, the waiting time is becoming excessive. Is there a way that could avoid using wait command?

Thank you in advance!
________
Penny stock

[Bob Hansen]

Rather than using Wait>n can you use other Waitxxxx or IF commands that are more responsive to activities?

Look at all of the Waitxxxx commands, including

WaitWindowOpen
WaitWindowClosed
WaitWindowChanged
WaitPixelColor

IFFileExists
IfFileChanged
IfDirExists

[pgriffin]

The only dependable way to know when your Emulator is ready for input might be to use Image Recognition. So create a bitmap of the image on the screen that signifies that the screen is ready for input and instead of simple wait, use a WaitScreenImage>Filename.bmp, then go to the next command.

WaitScreenImage>GreenLight.bmp
send>Data
WaitScreenImage>GreenLight.bmp
send>MoreData

etc....

Too many variations on this to even list, but that is where you should start.

[Me_again]

Is the emulator running a telnet session? If so your script may have more possibilities to react to responses if you use macroscheduler's own telnet functionality (in version 9) instead.

[Phil Pendlebury]

Wouldn't:

WaitReady>0

be useful for this purpose?

I am using this in a similar way in a script that runs things form the command line.

From help:

WaitReady suspends script execution until the foreground window has finished processing mouse, keyboard, show window, and optionally, paint events. Issue 1 to include paint events, and 0 to exclude paint events. This command can therefore be used to wait until the active application is ready to receive keyboard and mouse events in most situations.

[pgriffin]

Phil,

WaitReady>0 will, at best, detect when the Window which contains the emulator is ready for input, but will not detect when the application within the emulator is ready for input. If you only wanted to active a menu or toolbar item OF the emulator and not OF the application within it, then WaitReady> would help.

paul

[redsolar]

Thank you folks for your input. I think I could use waitscreenimage to solve my problems so far. But, it seems that the command "waitscreenimage" has a very long response time. I did a few tests to run the command in my emulator. At average, it took over 10 seconds to move to the next command, although the image is already there in the screen.

waitscreenimage>c:\SaveChange.bmp
MessageModal>FoundIt.

I was wondernig whether or not the system specification sets up some time paraments for this command, for example, refresh window every 10 seconds or so.

Is there any method I could dramastically reduce the response time for this kind of command?

Any commends on my questions would be greatly appreciated!!! Thank you folks.
________
Yamaha bruin 350 history

[Marcus Tettmar]

Well you can easily implement your own version of WaitScreenImage by using ScreenCapture and FindImagePos in a loop and you can set the loop delay to your liking. You can further speed it up by searching only a portion of the screen ... e.g. the object you are looking for is probably inside a specific window? So instead of searching the entire screen capture only that window. You may even be able to narrow it down further. E.g. if the image is always in the top right quadrant of a specific window you can reduce the area to search massively.

[redsolar]

Yeah, actually my screen image is a very small image which only contains a few words in it.

I open the window which has the image(always in the same positon) as the part of it, run the script. I still got a very slow response to recognize the image.

Any help on this?
________
Herbalaire

[Marcus Tettmar]

So don't use WaitScreenImage as it searches the ENTIRE screen. Instead use GetActiveWindow to get the dimensions of the window to search, then ScreenCapture with those dimensions and FindImagePos on that capture in a loop. Will speed it up big time.

[redsolar]

That's a good suggestion. I'll try that.. Thank you pro.
________
Wagoneer

[redsolar]

Oh, I checked with the past post and still didn't figure out how to use a loop to do that... Could you provide me an example close to my case? That would be valuable for me....
________
OXYGEN VAPORIZER

[Marcus Tettmar]

Ok, something like this:

Code: Select all

SetFocus>The_Window_To_Scan
GetActiveWindow>title,x,y,w,h
Let>x2=x+w
Let>y2=y+h

Label>scanloop
  Wait>0.5
  ScreenCapture>x,y,x2,y2,c:\window.bmp
  FindImagePos>c:\bitmaptofind.bmp,c:\window.bmp,20,1,XArr,YArr,numfound
  If>numfound=0,scanloop

Don't try to run this as is - it is fictitious and requires real window names etc. Use as a skeleton. It will wait for an image in a window, rather than on the entire screen.

[redsolar]

I wrote something like this:


Let>x=1
Repeat>x
GetScreenRes>sX,sY
ScreenCapture>0,0,sX,sY,c:\screen.bmp
FindImagePos>C:\title.bmp,C:\screen.bmp,20,1,xPos,yPos,imgs
if>imgs>0
let>x=2
Endif
Until>x=2
send>y
press enter

does this help too?

Your code looks complex to me. If mine doesn't work, I'll dig on yours. Thank you so much though.....
________
MAZDA XEDOS 6 SPECIFICATIONS

[Marcus Tettmar]

Your code searches the ENTIRE screen TWICE. Not at all what you want.

My code is about as simple as it gets. All you need to do is replace The_Window_To_Scan with the window title of your window.