On Wed, Oct 7, 2020 at 10:53 AM Nikolay Sivov bunglehead@gmail.com wrote:
On Wed, 7 Oct 2020 at 18:35, Jeff Smith whydoubt@gmail.com wrote:
On Wed, Oct 7, 2020 at 2:24 AM Huw Davies huw@codeweavers.com wrote:
On Tue, Oct 06, 2020 at 11:22:29PM -0500, Jeff Smith wrote:
Signed-off-by: Jeff Smith whydoubt@gmail.com
Testing revealed that SetBkMode() does not treat 'invalid' values as one might assume. Discovered this when working on another issue. Note that fixing this to match Windows simplifies one of the tests for that bug.
Which then begs the question: How should these invalid modes be treated visually?
FWIW, testing In Windows points to the default being transparent. That implies that any wine code that checks this value should check for equality/non-equality with OPAQUE to be "safe".
What ends up in metafile record for invalid modes?
It contains the unaltered value for both valid and invalid modes, as a little-endian 32-bit signed int of course.
Tested with -1 0 1 2 3 0xdeadbeef.
I tested on wine, with the patch applied, and got matching results.
Since there doesn't appear to be a real application that depends on this, we should keep things as they are.
Would be nice (and removes 8 unnecessary lines of code), but no real harm in leaving it as it is.
Thanks, Jeff