https://bugs.winehq.org/show_bug.cgi?id=51899
--- Comment #9 from Bruni earns.61@gmail.com --- (In reply to O. Nykyforchyn from comment #7)
I found out what causes the bug. When background is erased, a handle to DC is passed through USER16 functions, namely CallWindowProc16 (USER.122) and DefDriverProc16 (USER.255), whose respective parameters are of type WPARAM16, hence the upper part of the handle is cut. Later the returned handle is rejected by get_dc_attr() in GDI32 because its type is 0, although such handles are accepted by handle_entry(). Allowing type==0 in get_dc_attr() solves the problem both in WinEdt and Collins Dictionary. If there are no objections, I will submit the patch.
BTW, have you managed to figure out what's the 0x1f0000 magic number stands for? I could not find an explanation in Wine source.
It seems it may take really long time to investigate DC attributes with unclear semantics the next time it will be broken (which seems inevitable).
Each time someone fixes a bug and the expression if this 'if' becomes more monstrous.
If you have found out what the beast is 0x1f0000 there is a point to decomposite that monster expression in 'if' into a few branches.