findAll: endless loop when only using hasNext() - matches have to be consumed with next()
-------
The reason behind:
Per definition (see docs of findAll()), the returned Iterator does only step to the next iteration, if the current is consumed (done by using it.next()).
This means you implementation with only using hasNext() is an endless loop by default.
Conclusion: It is not possible to count the matches of findAll() without consuming the matches.
So if you need the matches later, you have to store them whicle counting.
There is convenience feature findAllList(), that returns a List<Match>, which is empty on no success.
see docs:
https:/
-------
I have a simple Java method witch will reproduce a extrem critical problem. I can run the following method between 1-3 mins, but always after a unspecific timespan my complete java app is frozen/hanging (no exception, no further log, no stacktrace). The last log lines before the error occurs are:
[debug] RobotDesktop: captureScreen: [1213,115, 150x400]
[840595 debug] Finder2: makeMat: INT_RGB (150x400)
[840595 debug] Finder2: doFind: start
[840600 debug] Finder2: doFind: in original: %99,9901 (?90) 5 msec
[840602 debug] Finder2: doFind: end 7 msec
[840602 debug] Region: findAll: BuildQueueEntry.png has appeared
It seems that the appearing of my image on the screen causes this critical bug. After this event the java app hanging for ever
// The intention of this method is to count the occurence of my image
private static int getBuildQueueSi
dsoService.
int counter = 0;
Region searchRegion = Region.create(1213, 115, 150, 400);
Iterator<Match> it = null;
while (true) {
try {
it = searchRegion.
while (it.hasNext()) {
}
} catch (FindFailed findFailed) {
}
}
}
OS: Win10
Java: 1.8.0_181
Sikuli: 1.1.4-SNAPSHOT
IDE: Intellij Idea
Window Commandline Execution
I hope you can help me with a Fix or Workaround!
Joe
Question information
- Language:
- English Edit question
- Status:
- Solved
- For:
- SikuliX Edit question
- Assignee:
- No assignee Edit question
- Last query:
- Last reply:
This question was originally filed as bug #1789952.