CODEWITHSUNDEEP
c#visual-studioformswinforms
Grasshopper
Grasshopper

Reputation: 4977

Form Constantly Turns White in Designer

The main form of my application constantly turns white in the designer when I perform the following steps:

  1. Open form in design mode (All controls are visible at this point)
  2. View source code for form
  3. Switch back to design view

After performing the steps above, there is nothing visible in design mode for the form (not even the form).

I only have this issue with one form in my application and, unfortunately it is my main form where there is a lot of logic. The workaround is to always close the form and reopen it in design mode show that all the components are visible again.

I have experienced erratic errors with the designer when I am low on available memory but, this form always produces this symptom and is the only one.

Any ideas as to what is causing this? I guess I could always create a new form and try moving all the controls and logic over but, I'd prefer to avoid the work if there is a simpler option.

Upvotes: 1

Views: 1042

Answers (3)

Miguel Tomás
Miguel Tomás

Reputation: 1911

You defiantly should check the next link: https://weblog.west-wind.com/posts/2019/Feb/14/WPF-Hanging-in-Infinite-Rendering-Loop?fbclid=IwAR23ZnUrz7buVpFLXOX2qQin1WcifQ6h280EO25URO74NTGDkTedx1TDRb4

here's a quote from the page:

Using the StarDefinitionsCanExceedAvailableSpace Override This setting overrides the new GridRendering behavior and basically lets you run with a .NET 4.7.x target in your project, but keeps the old behavior that was used in previous versions.

There is a configuration setting that can be set in app.config for your application:

<configuration>
     <runtime>
        <AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true"
     />
    </runtime>
</configuration>

I can verify that using that switch lets me run 4.7.1 and not see the lock up in any scaling mode. After I

had my running version in 4.6.2 back, I once again moved up to 4.7.1 in a separate branch to try this out and sure enough the switch made the application run targeted with 4.7.1. So there's a hacky workaround.

It's a workaround though. This 'fix' according to Microsoft improves grid rendering allocations, providing more precise sizing and also improves performance and reduces memory usage. On paper this is a great improvement, but... well, side effects 😃

I suspect this issue is not wildly common as there was not very much info to be found about it. I think Markdown Monster makes this issue come up because the startup sequence has a lot of window manipulation. MM uses the MahApps UI framework which uses Window Animation and extra rendering frames for the main window, and MM itself moves the window offscreen for initial render and adjusts window sizing based on screen sizes and DPI settings if the window doesn't fit on the screen or would otherwise be offscreen. IOW, there's a bit of gyration to get the initial window onto the screen that is more likely to hit this bug than a simple WPF form.

So I doubt that every application needs to worry about this, but if you have a 4.7.x WPF app it might be a good idea to try it out at various resolutions and scale levels just to see how it fares.

Upvotes: 0

Robbie Dee
Robbie Dee

Reputation: 1977

From personal experience, I can confirm that this is an occasional issue in both Visual Studio 2003 & 2005 whether VB or C# is used. We patched both versions to the latest service pack and even got hotfixes directly from Microsoft, neither of which resolved the issue.

In the case of VB in Visual Studio 2003, the disappearance of the controls also removed the underlying designer code so we kept having to restore the deleted code from our version control system. Very annoying - as we'd often lose code changes and have to start over.

Upvotes: 0

Hans Passant
Hans Passant

Reputation: 941227

The diagnostic is that the Paint event or OnPaint method of a control is misbehaving. These methods run at design time so you'll get an accurate visual representation of the control, the way for example that you can see the Image property of a PictureBox at design time. When such a paint event gets stuck in a loop then the entire form stops rendering properly. Beyond a simple bug, the typical reason is that the code is getting confuzzled by the non-standard runtime environment in design mode. You use the DesignMode property to ensure that such code won't cause trouble and is disabled in design mode.

Finding the misbehaving code is the challenge, especially when these are not controls you wrote yourself. Short from removing controls one by one to find the troublemaker, you can use the debugger by starting another instance of Visual Studio and use Tools + Attach to Process to attach to the first one.

Upvotes: 2

Related Questions