WaitForAll -> FoundImageLocations()??

Hi,

i often use the WaitFor X, image Command to wait for an image a given amount of time. When its found, i use the FoundImageLocation() Function to get the hotspot of the found image and for example click on it.

Now i want to use WaitForAll X, image1, image2, image3, image4 Command to wait for 4 Images. Is there a chance to get all coordinates of the found images without searching for every image on its own?

or is there an other solution/workaround?

thx, br

I guess my best suggestion would be to use the everyImageLocation function with the same list of images after the WaitForAll:

put everyImageLocation("image1", "image2", "image3", "image4") into imageLocs

There is a caveat though: If any of these images appears more than once on the screen, then you will get a list with more than 4 sets of coordinates because everyImageLocation is designed to look for multiple occurrences of an image. But if each image in the list appears just once, then this will return a list of the positions in which each one was found.

Hope that helps.

i tried the EveryImageLocation workaround, but there are some “problems”:
-first, EveryImageLocation (of course) searches again, and it takes much longer than the WaitForAll command
-second, if i call the EveryImageLocation command with more images, than the result coordinates do not have the same order like the images. for example


put EveryImageLocation image1, image2, image3, image4 into locations
put locations -- ((coords image4), (coords image3), (coords image2), (coords image1))

It looks like the result is always in the reverse order…

But, maybe you know a better approach: i want to wait for four images to appear and i need to know, where they were found. AND in the most effective/fastest way. Is there a difference in the speed if i use four WaitFor commands or one WaitForAll command?

thx, br klemensl

[quote=“klemensl”]i tried the EveryImageLocation workaround, but there are some “problems”:
-first, EveryImageLocation (of course) searches again, and it takes much longer than the WaitForAll command[/quote]
Searching again is going to be unavoidable. The good news is that you know all the images are present because of your WaitForAll command, so the subsequent searches can be quick. The reason that the EveryImageLocation search takes a while is because it searches the whole screen for each image, rather than stopping once it has found the image. Again, this is because it’s designed to find every location of a particular image. It may also search the maximum amount of time before returning it’s results.

[quote=“klemensl”]
-second, if i call the EveryImageLocation command with more images, than the result coordinates do not have the same order like the images. for example


put EveryImageLocation image1, image2, image3, image4 into locations
put locations -- ((coords image4), (coords image3), (coords image2), (coords image1))

It looks like the result is always in the reverse order…[/quote]

If this were the main problem, you could quickly reverse the list, either by reversing the list of images to look for in the command or after the fact in code:

repeat with each item of locations
    insert it before temp
end repeat
put temp into locations

Four WaitFor commands would take the longest possible time. Since you don’t know what order the images will appear in, the odds are that one of the first 3 WaitFors will be looking for the last image to appear – the images that the subsequent WaitFors are supposed to find will just be sitting there while the earlier WaitFor keeps looking for its image. Then once the last image to appear is found, the remaining WaitFors will get to do their searches. The WaitForAll command is going to be quicker because it keeps looking for each image, so it should find them more or less in the order they are displayed (there’s an element of uncertainty, but I’d have to go into a long description of the search process to explain it.)

The quickest implementation will probably be the WaitForAll command followed by 4 individual ImageLocation() function calls. ImageLocation scans the screen just until it finds the first instance of the target image, so it will be quicker than everyImageLocation(). You know the image is already on the screen, so the search will be quick – no screen refreshes will be needed. For the quickest possible execution, you will want to wrap this code in calls to reset the Remote Work Interval (the delay between image-based commands):

put the remoteWorkInterval into RWI
set the remoteWorkInterval to 0
WaitForAll 5, image1, image2, image3, image4
put ImageLocation(image1) int loc1
put ImageLocation(image2) int loc2
put ImageLocation(image3) int loc3
put ImageLocation(image4) int loc4
set the remoteWorkInterval to RWI

There are still some small delays present because eggPlant will check for screen updates before each search – they should be pretty inconsequential, but you can eliminate those as well if you feel it’s absolutely necessary.

thx, i take the combination of WaitForAll + ImageLocation(image1-4), its fast enough.

@EveryImageLocaion: i know how to reverse the order, but the fact, that the result is in reversed order sound like a “feature” to me. Maybe you could verify this behavior yourself and correct it, if it is really a bug.

@WaitForAll//FoundImageLocations: Maybe you could implement the FoundImageLocations() Function in a next release (with the result locations in the same order as the images) :slight_smile:

br klemensl

The coords are presented in order from left to right and top to bottom – it has nothing to do with the order of the images in the list. Your particular situation is not typical of why you would use multiple images in the command, I just thought it might work for you; I didn’t realize the order mattered to you. You might, for example, want to find all the checkboxes on the screen whether they are checked or not, so you would have one image for each and you would get a list of the positions of all the checkboxes. If you actually cared about the positions of just the checked ones, you would have an everyImageLocation() function with just the checked image. The other reason that the order wouldn’t matter is that if the function returns a list of 10 coordinates, you wouldn’t know whether it found 10 of one image and none of the other or some other combination of the two.

I’ll log it as a feature request, but I’m not sure it would be that useful. I don’t really think that tying the order of the coordinates returned by one command to the order of images listed in a previous command is a really good idea – it just doesn’t feel like a sound basis for the command.

[quote=“EggplantMatt”]
I’ll log it as a feature request, but I’m not sure it would be that useful. I don’t really think that tying the order of the coordinates returned by one command to the order of images listed in a previous command is a really good idea – it just doesn’t feel like a sound basis for the command.[/quote]

maybe there is a better solution, but i like the functionality of “Waitfor” + “FoundImageLocation”, so why not implementing something similar for “WaitForAll”? Maybe the return value of “FoundImageLocations” is something like a property list (image1:(x,y), image2:(x,y),…) so the order does not matter…

just think about it, maybe you find a solution which fits better.

thx, br klemensl