Skip to content
This repository has been archived by the owner on Sep 2, 2021. It is now read-only.

Fix for #10686: White line along right edge of UI on high-DPI Windows #507

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nethip
Copy link
Contributor

@nethip nethip commented Mar 6, 2015

This is a fix contributed by @fxb. This fix address the thin white line problem that appears just below the menu bar randomly.

@nethip
Copy link
Contributor Author

nethip commented Mar 6, 2015

CC @JeffryBooher @redmunds @peterflynn Please review this change.

@@ -816,7 +816,7 @@ LRESULT cef_dark_aero_window::WindowProc(UINT message, WPARAM wParam, LPARAM lPa
if (mReady) {
UpdateNonClientArea();
}
break;
return 0L;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to work ok but the app frame is no longer drawing in the active color when activated.
My guess is that Windows isn't sending WM_ACTIVATEAPP because you're preventing the WM_ACTIVATE message from reaching the default Window Proc but I haven't debugged this to determine if that is indeed the case.

    case WM_ACTIVATEAPP:
        mIsActive = (BOOL)wParam;
        UpdateNonClientArea();
        break;
    }
    return lr;

I guess technically you could just keep track of the active state from here but I wonder if there are other things that are broken.

@nethip
Copy link
Contributor Author

nethip commented Mar 9, 2015

@JeffryBooher Thanks for pointing out this and proving more info! I will look into this.

@deandersson
Copy link

@nethip to be able to get the menu bar to render in the active color we can add mIsActive = (BOOL)wParam;to the WM_ACTIVATE case aswell since the rest of the function is the same.

But as @JeffryBooher pointed out what else might be broken?
MSDN has a remark about the WM_ACTIVATE message, that DefWindowProc handles keyboard focus when the window gets activated. I tried this by opening a second instance from the debug menu and when DefWindowProc doesnt run the second instance never gets keyboard focus, so you can click in the second instance and activate it but when you type it goes in the first instance..

I could not replicate this problem when switching between other processes though. I tried several variations and could not really find anything that was broken when using this fix. There are probably more variations I could try but its over midnight now.. soo nighty night! 😄

@JeffryBooher
Copy link
Contributor

We should try playing around with the Window Class and make the background brush black. It's white by default. That might minimize the White Line flicker.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants