[.net] System.OutOfMemoryException caused by StatusStrip

Started by
3 comments, last by Kudaba 15 years, 2 months ago
I have a VS 2005 C++ Winforms project and I placed a statusstrip and toolstrip on the form. I was able to compile and run it just fine. I then closed VS and reopened the project and now everytime I try and view the form in designer mode, it throws an exception saying: The control System.Windows.Forms.StatusStrip has thrown an unhandled exception in the designer and has been disabled. Exception: Exception of the type 'System.OutOfMemoryException' was thrown. Stack trace: at System.Windows.Forms.StatusStrip.WndProc(Message& m) Does anybody know why this is happening? So far there are probably about 30 header files and 30 source files in the project. I'm also compiling in cli not cli/pure, and I have precompiled headers turned off. Also note this does not happen in C# projects, only C++. This ONLY happens in designer mode. Once I run the application it looks just fine. ***EDIT***** Also, this only occurs with the Toolstrip and Statusstrip. No other controls throw this exception.
Author Freeworld3Dhttp://www.freeworld3d.org
Advertisement
The user interface editor in Visual studio sometimes gets confused when there are multiple controls on the form after controls are added, parented, and then removed.

There are only a couple of workarounds.

* Keep numerous backups and go back to a working copy when things go bad.
* Don't place controls on top of other controls unless absolutely necessary. Meaning --> don't place a bunch of controls where they ought not go... ie.) like a menu strip on a panel.
* Tabbed controls are pretty bad.
* Basically anything that is a parented control has trouble.

Why is all this the case you might ask???

Microsoft in an attempt to maintain backwards compatibility (and possibly to save money -- though I doubt that) ... used the old com controls in .Net (They are just wrapped up, but not very well done.) Lot's of bugs.

The tool strip and status strip are newer controls. Probably custom drawn with GDI+. They are mostly tested under runtime conditions. GDI code acts different in the IDE (during debug time) because the IDE tries to draw the control on the form even though a lot of initialization code is "skipped" during an interpreted pre compile phase.

So... that's the long answer. :) Hope that helps.
If it makes you feel better, it drives me crazy too. I wrote my own controls to get around the garbage that MS provided. The underlying framework is actually a lot better than the controls that they provided us.

Thanks for your input. This problem has been driving me crazy all day. I thought maybe I had found a pattern to when the exception is thrown, but I hadn't. I currently have unmanaged and managed C++ code in my project, so I thought that might be causing it. So I removed any references to the unmanaged code in the form's header file, but that did not work. I don't know what to do, this is ridiculous. I don't understand why if it works just fine in C#, they can't make it work in C++.

Do I perhaps need to wrap all the unmanaged code in #pragma unmanaged statements?


**EDIT**
Also, why is this problem not documented anywhere? I've looked through every msdn article and google search result I could find, and nowhere is this issue ever brought up!
Author Freeworld3Dhttp://www.freeworld3d.org
Well I discovered if I "Clean" my project I can view the form in designer mode just fine. But as soon as I compile and try to view the form again, the exception is thrown. So I just re-CLEAN it.
Author Freeworld3Dhttp://www.freeworld3d.org
I need to thank you very much. This was bugging me for a while and I can't believe they still haven't fixed it after all this time. The clean solution definitely fixes the problem so thanks again for saving the day. :D
This Space for rent.

This topic is closed to new replies.

Advertisement