Develop Reference

Showdialog Make the Parent Form Flicker in MONO (2.10.9)

I create a winform application with .NET 2.0.
And I use mono (version 2.10.9) for none-dotnet system.
But in the mono mode, when I use "new Form().ShowDialog()" or just show a message box "MessageBox.Show()", the main form flickers.
I think when it triggers the showdialog method, the main form runs something like "enable = false" through the controls, which costs some time and the flicker.
Is there anyone have some idea to solve that?
Thanks.
btw, I am checking the code in the mono branch:
https://github.com/mono/mono/blob/master/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Form.cs
hope to solve this issue!!!!!

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.

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.

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.

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.

WinForms application becomes randomly unresponsive

We are building a WinForms based app (using .NET 3.5)
Recently i have encountered that when performing one of our application's main workflows, the application will become unresponsive in a matter of seconds, failing to properly render the UI (Shows the "Program is not responding" message).
We have reduced the issue to a suspected line of code that adds a tooltip to a label control:
ToolTip tooltip = new ToolTip();
tooltip.SetTooltip(label, "something");
I have spent the past 2 days figuring out what in this code could code any issues with the UI thread, but failed to do so.
My question is -- is it possible to use a performance profiler to gather information about code such as this? Note that the ToolTip class belongs to WinForms and i do not have the source code available for it.
Removing these lines seems to solve the issue completely.
I would like to reduce debugging efforts in the future, as this issue can manifest in other locations of our codebase.
EDIT:
The only similar reported issue i could find was this: WinForm ToolTip.SetToolTip is Hanging my application :(

You could use a program such as JetBrains DotTrace to see what is happening that actually causes the program to halt

I have the same problem, except I use a ToolTip object placed using the designer and then in the Popup event of the ToolTip I set the text for the ToolTip.
The problem only occurs on Windows 7 64-bit (I don't have a possibility to test 32-bit Win7), on 32-bit Windows XP, this works fine.
edit: i guess there was some recurrent calling of the popup event, because when i moved the tolltip setting to other place of my code, it works OK.

I know that this is an old question, but the hanging still happens on Windows 10 64-bit edition. On Windows 10 32-bit everything works fine. I have not looked at the .NET source code, but it must be a wait or something. So to overcome this problem I added the following workaround:
this.Invoke(new Action(() =>
{
tooltip = new ToolTip();
tooltip.SetTooltip(label, "something");
}
));
I was already calling this from the main thread, so according to MSDN documentation this doesn't make sense, but it releases the wait lock or something.

silent crash Win7 64bit on ResumeLayout() with winforms and C#

I'm building a Windows Forms application in C#, and testing on Windows 7 64bit revealed a silent crash.
The exact line that it fails on is this.ResumeLayout(false); near the end of the InitializeComponent() function. It's a part of the Visual Studio generated code from the Forms Designer.
There is no exception, no popup to show the program has crashed, nothing. It simply ceases to run once it hits that line. This only occurs in 64bit. Removing that line, the program runs, but cannot be maximized, and there are several other oddities related to window properties.
I've tried everything from changing build settings to using CorFlags.exe, nothing has helped. What could be the issue?
If it makes a difference, I'm using OpenTK and the GL Controls.

Had an identical problem, only in my case the software ran on some 64-bit systems and not others. For example, my laptop is a vaio pcg series bought just this year. 64-bit Windows 7 Home Edition, 1600 x 900 resolution. Program runs just fine here. My colleague has a vaio svz series, 64-bit Windows Professional with 1920 x 1080 resolution, and for some reason his kept getting the silent crash on the ResumeLayout(false) call.
Again, commenting out the this->SuspendLayout() call near the top of the INitializeComponents() sub, and the this->ResumeLayout(false) call near the bottom fixed the problem, and the program seems to run fine on both systems now.

I had the same exact problem with ResumeLayout(). It ran fine on several machines, but I had one user who had it throwing "Exception has been thrown by the target of an invocation." Not very helpful. Unfortunately they also hide some of the details from Exception.StackTrace. I consulted with our resident expert and he felt it was a resizing issue. I discovered exactly where the problem was after going to DEBUG-->Exceptions and selecting everything. I then got a break right inside a function I was using to reposition some checkboxes. For some reason this was throwing an out of range exception on this user's box...
Rectangle rect = dataGridView.GetCellDisplayRectangle(col, row, true);
The point being that selecting the break on exceptions options as I described helped me pinpoint the actual problem. The workaround that others mentioned is fine, but in this case I was able to find the root cause.

Do you use some external component?
Some OCX which is not compatible with 64bit? I had your same trouble using GdPicture.
If so, try to compile for 32bit and problem could be solved.

A simple solution to this whole ordeal was to simply remove both the offending ResumeLayout() call and its corresponding SuspendLayout() call at the beginning of the InitializeComponent() function. It seems to have had no ill effect on the layout of the window despite having a heavy number of controls on the window. Again, this was only for 64 bit machines, the issue never popped up on Windows XP or 7 32 bit.
I'm still baffled as to why the ResumeLayout() call was causing a silent crash in the first place, and still feel slightly uneasy about the "solution", but it seems to have worked.

Why I get an "Canvas does not allow drawing" while drawing in TeeChart ActiveX 5 component?

I'm using Steema's TeeChart ActiveX 5 component for an application in .NET C#.
I do some drawings using the methods Line(), Rectangle() and Circle() through the "Canvas" property of the component.
My code for drawing is called on every on every OnBeforeDrawSeries() and OnAfterDraw() events of the component.
When there is only a few drawings, it works ok. But when the amount of drawing increases and after a certain number of redraws, I get an MessageBox with an error "Canvas does not allow drawing" and the application quits.
I believe this is somehow due to "overloading" the component with drawing calls.
Am I using this functionality the wrong way, or can I consider this a BUG in the component?

I would consider this a bug because I have a similar problem (not with Canvas) with this component and the way it manages the memory.
On some machine with small amount of RAM, when we create a lot of graph and display them, we will receive a message box with this message "Not enough storage available to process this command". Once this box appears, it is impossible to close this box because if you click OK, the message box is displayed again and again. So, you need to kill the application to get ride of it. I think the bug is related to the drawing process because when we close the message box, the component tries to repaint the region where the message box was displayed and the error happens again.
First, you know that TeeChart ActiveX is now at version 8. Maybe this version resolve this issue.
I would suggest also to try the .NET version of TeeChart. From my own experience, TeeChart .NET does not have any memory problem since the memory is managed by the .NET framework.