jiaojiaodubai

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.

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

Available AutoIt3 links that Winget is using Hello, as you can see from the Github link, Tenlys, the developer who previously added the AutoIt3 installation package to Winget, uses the following link for the AutoIt3 installation package in Winget: https://www.autoitscript.com/files/autoit3/autoit-v3-setup.exe (hereinafter referred to as Winget-Au3 for convenience). The Winget program can normally obtain the installation package of AutoIt3 from this link. The SciTE4AutoIt3 links obtained from the official website cannot be accessed by Winget. The link I submitted to Winget about SciTE4AutoIt3 is https://www.autoitscript.com/cgi-bin/getfile.pl?../autoit3/scite/download/SciTE4AutoIt3.exe (hereinafter referred to as Official-Sci4Au3-Raw for convenience). Official-Sci4Au3-Raw is obtained from the download page of SciTE4AutoIt3 through the mouse shortcut menu "Copy Link". Winget developer Borque pointed out that Official-Sci4Au3-Raw points to https://www.autoitscript.com/autoit3/scite/download/SciTE4AutoIt3.exe (hereinafter referred to as Official-Sci4Au3-Target for convenience). The current situation is that autoitscript.com prevents the Winget program from automatically obtaining the installer of SciTE4AutoIt3 from Official-Sci4Au3-Raw or Official-Sci4Au3-Target, and returns the information "403 - Forbidden". Can't guess the available SciTE4AutoIt3 link according to the available Au3 link Borque tried to imitate the address form of Winget Au3 to write Link 1, Link 2 and Link 3, but these links are invalid (perhaps SciTE4AutoIt3 really has a download link similar to Winget Au3, but we didn't guess the correct one). Conclusion Therefore, Winget is unable to access Official-Sci4Au3-Raw and Official-Sci4Au3-Target in its crawler now(Of course, these two links are still valid for users who use browsers to access them, but they cannot be accessed by Winget's automated robots.), nor can it "guess" the SciTE4AutoIt3 download link available like Winget-Au3 according to the existing information. Borque hopes that we can change the security policy of Official-Sci4Au3-Raw or Official-Sci4Au3 Target, so that Winget programs can capture the installation package of SciTE4AutoIt3 for automatic package management, or we can provide other available links about SciTE4AutoIt3 like Winget-Au3.

AutoIt3 can be downloaded and installed in Winget, but I don't know whether they use a link similar to the one I submitted (that is, a link from autoitscript. com). The support for installing AutoIt3 in Winget is created by other Winget developers. Maybe the link they use is not from autoitscript.com, or they have the technical ability to "click" our link in the automated robot. I have tried to contact the developers who have submitted the AutoIt3 installation package in Winget for more details. Thank you for your quick reply. I will let you know if there is any new progress (of course, you can also see the progress in Github issue I gave at the beginning).

I am happy to see that the latest version of AutoIt3 can already be searched, downloaded and installed in the Windows 10+built-in package manager (Winget). Therefore, we can automatically install AutoIt3 itself by writing Powershell scripts, which helps to quickly deploy the working environment of AutoIt3 on new machines. Now, although AutoIt3 can be found and installed in Winget, its dedicated editor, SciTE4AutoIt, does not support this. I submitted a package request for SciTE4AutoIt to the Winget development team on GitHub and provided a download link. Then its developer replied to me: In other words, Winget developers believe that our website prevents Winget from directly downloading the .exe file of SciTE4AutoIt. In fact, I don't know much about the technical details he said, but I think we can make some changes to make SciTE4AutoIt more accessible.

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.）

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.

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…

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