Too Many Windows

snarfblam

Ultimate Contributor
Joined
Jun 10, 2003
Messages
2,097
Location
USA
I've brought it up in the past, but I feel compelled to make an issue of it again. Windows Forms is sorely lacking what is known in the VB6 world as "light-weight controls," or, controls that don't own their own window, and instead share their parent's window.

The reason that I bring this up is because I am writing a program that includes calculator functionality, and am basing my calculator loosely on the Calc.exe program included with Windows. You know the one, with lots and lots of buttons. With only a fraction of my buttons in place, the price I pay for having that many windows becomes abundantly clear. In the ballpark of 25 buttons, with each redraw, I can see each button being drawn as the form takes image painfully slowly. This is on my laptop, and I'm sure that there would be quite a difference on my desktop, but the fact is that my program will be used on, at least, my own laptop if not others.

I wrote my own LightweightControl class, which I inherited to create a LightweightButton class. At this point both of the two are very far from finished, but the drawing speed seems to be an order of magnitude faster, and visually indistinguishable. Before I put hours (or, more likely, days) of effort into writing complete light-weight controls (which could never be supported by the designer...) I was wondering if anyone else has run into this type of problem and what other approaches have been taken to solve it.
 
Buttons are not lightweight

I agree completely that lightweight controls should be supported in some form or other (eg labels), but when have buttons ever been lightweight? Buttons have always been their own windows, instances of the BUTTON window class. Open up Spy++ with Calculator running in scientific mode and you'll see that every button is a window. Not that this helps you, but clearly the problem lies in framework overhead.

As for tips, how about making your lightweight controls able to instantiate themselves from their heavyweight equivalents? This way, you could use the regular buttons/etc in the designer to design the form, and convert them all at runtime.

Good luck :)
 
Re: Buttons are not lightweight

MrPaul, you are correct that buttons have never been light-weight, but UserControls had the option to be light-weight and it would be much easier to build a button from a UserControl than completely from scratch. I now have to completely handle keystrokes, mouse movements, implement painting behavior, you get the idea, building it all from scratch. A UserControl would do 90% of the work for me.

As for your "hybrid" light-weight controls, I've been toying with the idea. It would probably be the best way to do things, but the implementation could get tricky. I think the easiest solution might be to have lightweight controls derive from the Control class so that they can create their own window and be hosted in the designer, but it would require some sleight-of-hand at runtime to either (preferably) prevent the window from being created, or immediately destroy the window.

As to the root of my problem, I know that the underlying problem isn't simply that each button has its own window. The problem is DotNets underlying form-rendering engine, which is slow. Using many windows exacerbates the problem to the point of intolerability. Using windowless controls allows me to circumvent DotNet's rendering system and implement my own. And I would like my approach to be clean, polished, functional, and re-usable because I have run into this problem before and I will run into it again.

The biggest arguments against windowless controls are that "handles are cheap" and it makes rendering (specifically, z-ordering and overlapping windows) very difficult, but for general use, where windows don't overlap but there might be a very large number of controls, even when controls can render quickly it is still a senseless waste of resources. At the very least, the option to have a window or share a parents window should be build into the fundamental Control class.

All that being said, I am still open to other options if they meet my needs.
 
Back
Top