PixelGetColor() returns wrong color on Win11

[jiaojiaodubai 0]

I plan to write an Au3 script to automatically install a PPT plug-in.

Because the button on the installation wizard of the PPT plug-in is not a standard control, I consider writing a while loop to constantly judge the color of a specific location on the installation wizard. When the plug-in is successfully installed, a blue "Start Software" button will appear at this location, so that I can let the script close the installation wizard window.

But when I used the PixelGetColor function, the script did not get the color of the button on the installation wizard. On the contrary, it went through this foreground window and got the color of my desktop background! However, Au3's window information tool can correctly return the color of this position.

The following is my script code (due to different configurations, some coordinates may need to be changed when testing on other devices):

;~ Run plug-in installation package
#RequireAdmin
run(@ScriptDir & "\FocoSlide.exe")
;~ In each installation, the number behind this class is different, so you need to use wildcards to match the window.
$tittle = "[REGEXPCLASS:HwndWrapper*]"
WinWait($tittle)
;~ Change the installation path
WinActivate($tittle)
Send("+{TAB}")
Send("+{TAB}")
Send("+{END}")
Send("{DELETE}")
ControlSend($tittle, "", "", "C:\Program Files (x86)\OfficePlugins\Foco")
;~ Switch focus to "Install" button and enter to confirm
Send("+{TAB}")
Send("{ENTER}")
$wh = WinGetHandle($tittle)
;~ Wait for the "Start Software" button to appear (installation is complete)
;~ Activate the window before each color acquisition to avoid potential errors.
WinActivate($tittle)
$s = PixelGetColor(763, 533, $wh)
ConsoleWrite("color is " & Hex($s, 6) & @CR)
While Hex($s) <> "0267EC"
Sleep(3000)
$s = PixelGetColor(763, 533, $wh)
ConsoleWrite("color is " & Hex($s, 6) & @CR)
WinActivate($tittle)
WEnd
;~ When the blue Start Software button is detected, the installation is completed and the installation wizard is closed.
MouseClick("left", 1043, 350)
Exit

Au3 version: 3.3.16.1
Operating system: Win11

[Danp2 1,382]

I suggest checking the value of @error following the call to WinGetHandle.

[Nine 1,634]

You did not set PixelCoordMode in your script.  On default, hWnd is simply ignored. (help file is your friend you know)

[jiaojiaodubai 0]

On 11/18/2022 at 9:11 PM, Nine said:

You did not set PixelCoordMode in your script.  On default, hWnd is simply ignored. (help file is your friend you know)

I manually started the installation package again until the "Installation Complete" window appears. At this time, there is a blue button. My goal is to let the script find the existence of this button. I wrote the following code to test the above window, but the output of the script is still not satisfactory. (Before running the script each time, I will manually switch my desktop background to confirm whether it affects the output of the script.)

#RequireAdmin
Opt("PixelCoordMode", 0)
;~ The coordinate mode of the mouse is the same as that of the pixel
Opt("MouseCoordMode", 0)
$tittle = "[REGEXPCLASS:HwndWrapper*]"
WinActivate($tittle)
$wh = WinGetHandle($tittle)
;~ Use the mouse to indicate whether the pixel location is correct
MouseMove(314, 222, 20)
WinActivate($tittle)
$s = PixelGetColor(314, 222, $wh)
ConsoleWrite("color is " & Hex($s, 6) & @CR)
; output: 42300C, FFDCD6…

 

[jiaojiaodubai 0]

On 11/18/2022 at 8:41 PM, Danp2 said:

I suggest checking the value of @error following the call to WinGetHandle.

Thank you for your reply. This is my first time to use @error. I referred to the help document and wrote the code below. It seems that there is no error in the process of obtaining the handle, but the output color is different from the actual situation.

 

[Nine 1,634]

Did you set au3info tool at the same level of Coord Mode as Opt ?  (both should be Window or Client)

 

[jiaojiaodubai 0]

On 11/20/2022 at 8:04 PM, Nine said:

Did you set au3info tool at the same level of Coord Mode as Opt ?  (both should be Window or Client)

 

Yes, I confirm that the coordinate mode setting of Au3 window information tool is consistent with that described in the code.

Today, I retested my code and found that it always returns a specific color number. Even if I change the desktop background (as before), the output color will not change, although it is still not the correct color. I entered the color number on a web color conversion tool and found it was the background color of my code editor! When I move the code editor window to the right of the screen (as I did in the last test), the script returns the color of the desktop wallpaper as it did last time.

Therefore, I guess that it is not the PixelGetColor function that "penetrates" the window of the installation wizard to obtain the wallpaper color, but the setting of PixelCoordMode or the handle parameter of PixelGetColor may not work, causing PixelGetColor to not obtain the color with the window I specified as the coordinate. In my case, PixelGetColor may always take the upper left corner of the screen as the coordinate origin, so the color obtained is the color of the area near the upper left corner of the screen.

However, as we can see, MouseCoordMode works when the coordinate mode is also set to the active window (parameter 0), and the mouse cursor can correctly move to the blue button. I don't know how the two functions work differently with respect to coordinates, but they do behave differently.

 

（To add, I have noticed that when the mouse hovers over the blue button of the installation wizard, the color of the button will deepen slightly, so my later test code has changed to output the color first, and then move the mouse to that position.）

[jiaojiaodubai 0]

Now I am almost sure that this is a bug on Windows 11.

In order to confirm the problem, I wrote a simple script to test. The tests were carried out on Windows 11 and Windows 10 respectively, and different results were obtained. The test samples and their results have been included in the attachment. The "demoWin. exe" program is compiled from "demoWin. au3", while the "demoWin. au3" code comes from Au3's help document.

Samples and Result.zip

[Nine 1,634]

Does it work if you remove the hWnd of the GUI ?  (I don't have W11, so I cannot test it)

In any case, you could use my Screen Scraping UDF (see my signature).

[jiaojiaodubai 0]

11 hours ago, Nine said:

Does it work if you remove the hWnd of the GUI ?  (I don't have W11, so I cannot test it)

In any case, you could use my Screen Scraping UDF (see my signature).

Disappointingly, even if I delete hWND, PixelGetColor still returns an incorrect color code.

I tried to use your UDF, and it did return the correct color!  Before the developers of AutoIt3 solve the bug of PixelGetColor function, the UDF you wrote will become my preferred solution. (By the way, I'm not sure whether it's appropriate to submit a bug on the "AutoIt General Help and Support" forum, or whether the developer will notice it.)

I have never used UDF imported externally before, and now I only test by modifying the code in the compressed package. In order to use it well, I will spend some time to understand these things. I suggest providing a simple help document written by Markdown in the UDF compressed package, including how to correctly configure the extracted files(may point to a webpage link), function parameter descriptions, and so on.

[Nine 1,634]

Glad my UDF works for you.  Thank you for providing positive feedback.  As for making a long and extensive help file, I will not doing it.  The UDF  is meant to be an example of the code that can be written in AutoIt. It is not intended to be a basic part of the package.