Pixel searching finding incorrect colour Topic is solved

[rubeusmalfoy]

I am testing a number of pixel searches and the below test keep registering on black (000000) or rather than the colour I'm searching for. With the variation set to missing (0) I would assume it's not that causing the issue. This seems to happen no matter what colour I have it search for.

Code: Select all

#Requires AutoHotkey v1.1.33.11
CoordMode, mouse, Screen
CoordMode, Pixel, Screen
F1::

Loop {
    pixelsearch, Bx, By, 550, 200, 1850, 1450, B97A57, , Fast RGB
    if (ErrorLevel = 0) {
        Msgbox RED found at coordinates: %Bx%, %By%
    }
    else {
        sleep 2000
    }
}

[gregster]

You are not using the correct number format for hex numbers, starting with 0x:

ColorID

The decimal or hexadecimal color ID to search for, by default in Blue-Green-Red (BGR) format, which can be an expression. Color IDs can be determined using Window Spy (accessible from the tray menu) or via PixelGetColor. For example: 0x9d6346.

Since colorID can be an expression, AHK v1 currently evaluates your color as a variable (which is probably blank = false = 0 = black color ID in decimal format).

Numbers

AutoHotkey supports these number formats:

• Decimal integers, such as 123, 00123 or -1.

• Hexadecimal integers, such as 0x7B, 0x007B or -0x1.

• Decimal floating-point numbers, such as 3.14159.

Hexadecimal numbers must use the 0x or 0X prefix, except where noted in the documentation. This prefix must be written after the + or - sign, if present, and before any leading zeroes. For example, 0x001 is valid, but 000x1 is not.

[mikeyww]

Also already here and with example! viewtopic.php?f=76&t=128557&p=569640#p569653

But good to have this additional explanation from gregster.

Some AHK commands use color strings without 0x, but the search commands do require the numeric format as shown.