Enhancement - PixelSearch to return the color it found

[anonymous]

Currently the PixelSearch function returns a two element array containing the x and y coords of the pixel it found. Please consider returning a third element of what color that pixel was. Because of the shade variation parameter, it may not be the color that was actually searched for, but a variation of it. Sometimes one needs to know what color was actually found, but doing another PixelGetColor call may not be completely valid because it's possible that the screen might have changed in between the two calls.

[TicketCleanup]

Automatic ticket cleanup.

[BrewManNH]

Why don't you just use PixelGetColor after the return from PixelSearch?

[Melba23]

/
Sometimes one needs to know what color was actually found
/
Really? Can you offer a real-world example of when this might be required because an immediate PixelGetColor call would not return the same value?

M23

[anonymous]

Can you offer a real-world example of when this might be required

A gaming bot for one. But one could also argue that it's an incremental improvement in design.

[anonymous]

Actually, this makes sense if you think about it in this way... What the PixelSearch function does is allow you to specify ranges, and it goes off and finds a specific value that matches those ranges.

It allows you to specify a range of X.
It allows you to specify a range of Y.
It allows you to specify a range of C. (Color)

It goes off and looks for a match and returns what it found.

It returns the matching X it found within the range of X you specified.
It returns the matching Y it found within the range of Y you specified.
But it does not return the matching C it found within the range of C you specified.

It would be an improvement to return all three of the matching parameters instead of just two of them.

Expecting the caller to make a second call to PixelGetColor is not only a needless waste of cycles, but it also expects the caller to depend on a race condition. They would get the correct value back from a followup call to PixelGetColor only if the screen didn't happen to update in between those two function calls. It's easy to argue that calling PixelGetColor gets you the info you need, but that would be arguing in favor of a race condition.

It seems it would just make sense to return all 3 matching params rather than just two out of three. It would not only eliminate the race condition issue, but it should also be minimal programming effort to return the extra value since it obviously is already being looked at internally, and it also would be a backwards compatible code change. It seems there is more benefit to do it than not to.

[Melba23]

/
A gaming bot for one
/
Not exactly the best argument to put forward to support your request - read the Forum rules to see why:

​https://www.autoitscript.com/forum/topic/169097-forum-rules/

/
an incremental improvement in design
/

Much better. ;)

I am not convinced that there is a need for this other than for gaming - "sensible" apps tend not to have elements with colour changes happening so quickly, nor do they normally require the use of colour ranges. But if it is easy to do.....we will let the Devs decide.

M23

[Jpm]

Fix sent to Jon