Opened 10 years ago
Closed 5 years ago
#3127 closed Bug (Fixed)
PixelGetColor ignore third HWND parameter
| Reported by: | petrsum@… | Owned by: | |
|---|---|---|---|
| Milestone: | Component: | AutoIt | |
| Version: | 3.3.14.0 | Severity: | None |
| Keywords: | Cc: |
Description ¶
The PixelGetColor function with passed HWND parameter should analyze a DC of the specified window. Now it still analyze a entire screen DC instead.
Probably, the issue is passing NULL to GetDC function always. As I understand the GetDC function call is a part of the PixelGetColor implementation.
This is a log of WinAPI functions that have been called by PixelGetColor function work in an attachment.
Change History (5)
Changed 10 years ago by petrsum@…
comment:1 Changed 10 years ago by anonymous
Perhaps, this bug causes a strange behavior of the PixelCoordMode option switching. Now it seems that the default (absolute screen coordinates) mode is used always.
comment:2 Changed 10 years ago by anonymous
HWND used only if "PixelCoordMode" 0 or 2. If 1 then HWND is ignored. So it was always.
comment:3 Changed 10 years ago by petrsum@…
I have checked a behavior with "PixelCoordMode" option equal to 2. GetDC WinAPI function that is called before GetPixel still receive a NULL as input parameter.
It is strange why processing of the HWND parameter should be tied with "PixelCoordMode" option. Expected result of the passing HWND parameter is possibility of getting a pixel color from an overlapped window.
comment:4 Changed 5 years ago by Jpm
- Resolution set to Fixed
- Status changed from new to closed
Yes it is strange but as changing the behavior will be a SCRIPT BREAKINg only doc was change
Guidelines for posting comments:
- You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
- In-depth discussions should take place on the forum.
For more information see the full version of the ticket guidelines here.
Screen-shoot of the PixelGetColor function call