NtUserMessageCall(..., NtUserSendDriverMessage) does not ensure the
validity of the hwnd, so this check will incorrectly fail if the
last error was ERROR_INVALID_WINDOW_HANDLE by coincidence. The
notify_owner call immediately following this code will catch a
destroyed owner hwnd.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3147
On Fri Jun 23 19:02:05 2023 +0000, Davide Beatrici wrote:
> I would expect the same behavior for `PFD_DRAW_TO_BITMAP` though. Aren't
> both the same flag "class"?
I guess we need more tests to be sure.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3111#note_36674
On Fri Jun 23 18:54:52 2023 +0000, Damjan Jovanovic wrote:
> I don't think it works like that. If the flag is set, it only returns a
> PIXELFORMATDESCRIPTOR with the flag set, but if it is clear, then the
> returned PIXELFORMATDESCRIPTOR can have the flag set or cleared.
I would expect the same behavior for `PFD_DRAW_TO_BITMAP` though. Aren't both the same flag "class"?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3111#note_36673
On Fri Jun 23 18:48:33 2023 +0000, Davide Beatrici wrote:
> For consistency:
> ```suggestion:-0+0
> if ((ppfd->dwFlags & PFD_SUPPORT_GDI) != (format.dwFlags & PFD_SUPPORT_GDI))
> ```
I don't think it works like that. If the flag is set, it only returns a PIXELFORMATDESCRIPTOR with the flag set, but if it is clear, then the returned PIXELFORMATDESCRIPTOR can have the flag set or cleared.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3111#note_36672