0

I support several Visual Studio 2012 MFC applications, and all of them are exhibiting the same bad behavior on Windows 10 only: resizing a docked pane (via mouse) leaves artifacts, i.e. garbage on the screen. The garbage looks like a series of lines that correspond to the intermediate positions of the pane edge being dragged. I can reproduce this behavior with a stock VS 2012 application, which proves that it's got nothing to do with my code. Here are simple instructions for replicating the bug.

In the VS 2012 New Project Wizard, select MFC Application and press OK. Accept the defaults for all options EXCEPT ONE: On the very last page (Generated Classes), change the Base class from CView to CScrollView. Then press Finish.

Now make the following edit. Find the line "// TODO: calculate the total size of this view" in OnInitialUpdate, in the view .cpp file. Change the size from 100 to 2000. The only purpose of this change is to ensure that the view has scrollbars.

Now run the resulting app under Windows 10. Try resizing the docked panes. Do you see the artifacts? They generally appear when the scroll view is getting BIGGER. Why is this happening? Would migrating to VS 2017 solve it? Or is Windows 10 now incompatible with MFC? Ever since I migrated to the "new" MFC (BCGSoft) features, I've been worried that their code is too complex and would break in some future release of Windows. It sure looks as if I was right to fear this.

MFC Win 10 docked pane resizing bug screenshot 1 MFC Win 10 docked pane resizing bug screenshot 2

victimofleisure
  • 107
  • 8
  • Is it possible that your window that is occupied by the pane doesn't erase its background and doesn't paint anything? – xMRi Jan 29 '19 at 10:25
  • That is not the case. Again this is a stock MFC app, none of it my code except the one line as explained above. The scroll view paints its own background, as does the dockable pane, yet the artifact covers both of them. I should add that on a different Windows 10 PC I tried this test on, the behavior was slightly different. The mysterious grey line still appeared at an offset from the pane edge being dragged, but it did NOT leave a trail of artifacts. So the failure mode seems to vary depending on some unknown factor. – victimofleisure Jan 31 '19 at 01:18
  • Clear the registry in HKCU. There might be some wrong entries in the registry that recreates the windows in a wrong way. – xMRi Jan 31 '19 at 06:56
  • @victimofleisure did you find any solution for this issue ? – Artashes Budaghyan Apr 04 '20 at 17:28
  • @ArtashesBudaghyan I didn't, no. Debugging my own code is bad enough, debugging the framework isn't good use of time unless it's absolutely mission-critical. – victimofleisure Sep 22 '22 at 15:53

0 Answers0