4

I'm supporting a .NET 4 WinForms app written in VB.NET and built w/ Visual Studio 2015. In Windows 7 things are fine, but in our Windows 10 testing there is a rendering problem with a form window in the main application window. Happens on multiple machines (all Dell laptops). Dragging form window quickly, and over the main window’s top or bottom edges (highlighted in yellow in screenshot), causes it to freak out and leave graphical artifacts, like so:

enter image description here

Are there window properties or settings that can be adjusted to prevent this?

thanks!

mdelvecchio
  • 567
  • 1
  • 5
  • 25
  • Are you dragging in a scrollable control? – Trevor May 12 '18 at 00:04
  • I'm dragging the form window over another window that has a grid of item rows, of which the user selects one and clicks an open-button to load the item details into the new form window), both of which are inside the main window, which itself scrolls as in the screenshot. Not sure if that answers your question tho. – mdelvecchio May 12 '18 at 00:38
  • It may be because you have an `Application.DoEvents` statement in one of the event handlers that fires while dragging. You could also try setting the form's `DoubleBuffered` property to `True` – David Wilson May 17 '18 at 07:59
  • Application.DoEvents not found in solution seach, and the form's DoubleBuffered is already set to True. hrrrm. – mdelvecchio May 17 '18 at 19:51
  • Is the flicker occurring on another machine? Perhaps your machine is the problem since it only occurs while running on Windows 10. Your choice of theme could be an issue too. Try changing the theme to the most basic one. – L0uis May 18 '18 at 17:46
  • It happens on multiple machines. No theme other than whatever is standard and default. – mdelvecchio May 19 '18 at 15:19
  • By default Windows 10 is more resource heavy than Windows 7. If your hardware didn't upgrade simultaneously with your operating system that could be your issue. Test your software on a pc with higher hardware specs and see if the problem persists. –  May 19 '18 at 21:41
  • 3
    Post minimal code that duplicates the problem. – LarsTech May 21 '18 at 20:40
  • It's not possible to add code that duplicates the problem as it's not a known technique or identified method that causes it. – mdelvecchio May 22 '18 at 17:01
  • @mdelvecchio, Hmm, that's called debugging. You try to narrow down the possibilities by excluding the parts that have nothing to do with the problem _chunk by chunk_ until you reach the minimal code that duplicates the problem. If you try and do that, you might even end up fixing the problem yourself. – 41686d6564 stands w. Palestine May 23 '18 at 00:50
  • Have you declared the application to be DPI aware via the manifest? If not do so and see if the problem still exists. – TnTinMn May 23 '18 at 17:13
  • @Ahmen, you don't seem to be understanding. This is not an code execution problem where a breakpoint will show me the issue. It's a graphics rendering problem, which is more nebulous in scope. Thanks for the pro tip tho. – mdelvecchio May 31 '18 at 21:44
  • @White Wolf - it's not a resource issue, as the laptops with the Win10 images are brand new and have more hardware resources than the current laptops they're replacing. – mdelvecchio May 31 '18 at 21:45
  • @TnTinMn - this is an interesting idea. These new laptops are extremely high resolution with a lot of pixels. I'll check into this, thanks – mdelvecchio May 31 '18 at 21:49
  • I've tried editing the .manifest by editing it in notepad and adding the process DPI-awareness properties as in this questions, but nothing yet... https://stackoverflow.com/questions/23551112/how-can-i-set-the-dpiaware-property-in-a-windows-application-manifest-to-per-mo – mdelvecchio May 31 '18 at 22:33
  • 1
    @mdelvecchio, notepad implies you attempted to add an external manifest file. For a long time now, VS embeds a default manifest that will preclude an external manifest file. Open the project in VS, from the Project Menu->ProjNmae Properties->Application Tanb click on the "View Window Settings" button. VS 2015 should have a default block for the DPI settings, but they will be commented out. Delete the `` surrounding the application block. – TnTinMn Jun 01 '18 at 00:34
  • @TnTinMn Ah thanks for the tip. I don't have any DPI elements commented out there, but will try adding them per the example here https://stackoverflow.com/questions/23551112/how-can-i-set-the-dpiaware-property-in-a-windows-application-manifest-to-per-mo. – mdelvecchio Jun 07 '18 at 22:14
  • editing the app.manifest via the project properties screen, re-building, and re-running didn't resolve my issue, unfortunatley. Tho the more I think about it the less DPI settings seem relevant...this is a painting/rendering issue of the child window in the parent window. I think I'll have to pursue more MDI-oriented fixes...thanks tho – mdelvecchio Jun 15 '18 at 19:56

2 Answers2

3

The repainting issues are generally attributed to the fact that the main thread may be locked doing some process and is not able to repaint. Are you using multithreaded approach in your application. A good starting point would be to check if there is anything locking the main thread.

Soham Dasgupta
  • 5,061
  • 24
  • 79
  • 125
1

Each WinForms Control has a property called DoubleBuffered. It is intended to reduce such unwanted effects. When double buffering is enabled, the rendering operations take place in the memory first. Then only the last one is applied to the graphics device. More details here.

Double buffering is disabled by default for forms. So setting the DoubleBuffered property for your form to true will resolve the problem.

UPDATE

I misread the comment stating that the DoubleBuffered is already set. Please, make sure the DoubleBuffered property is set for both your MDI child and MDI parent forms. Also, make sure that the driver for the graphics card is the manufacturer provided as opposed to the default one.

Bozhidar Stoyneff
  • 3,576
  • 1
  • 18
  • 28