Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

Is anyone doing anything HARD with .NET?

I wonder
I think that if you are a .NET developer of Windows application and haven't noticed that something strange is going on with docking, then you're probably not doing that complicated work, are you?

The funny thing is, googling to find answers to my problems with .NET development, I start to wonder if anyone is doing anything complicated using .NET. I also wonder if anyone is working in teams building windows apps at all.

Why am I wondering these things? Because when I started doing Windows development recently (professionally, I have been dabbling with simple things as well, before this) where the application is supposed to look professional AND have a shitload of features of the more complicated variety, I started noticing things that were... not really that well documented in .NET. Things that seem simple (at least when reading the articles available on the subject on MSDN and the web in general) turn out to be complicated. Things that should be automatic are not. Things that you take for granted explode in your face.

What the HELL is wrong with AutoScaleBaseSize?
OK, what is AutoScaleBaseSize? According to the documentation it is:
"The value of the AutoScaleBaseSize property is used at form-display time to compute the scaling factor for the form. The autoscaling base size is used by the form as a baseline for comparison to the system's font size to determine how much to scale the form when autoscaling is used. If you want to determine the size a form will auto scale to based on a specific font, use the GetAutoScaleSize method.
Note The value of this property is used when the form is initially created. Once the property is set, it cannot be changed."

OK, I think I get it. It contains a value representing the font size you the developer is currently using when designing the form. This gets stored (this is how it appears to me, anyway) in this property. When loading the form, .NET compares this value to the size of the actual system font being used on your particular computer to scale the form accordingly.

Why are we getting fucked up form-sizes in our project then? Well, because this value is set by the designer, everytime you open the form in VS.NET. So, if I am editing a form and using a font with size 5/13 and you edit a form using a font with size 6/15, those forms will look different on both our computers. We started noticing this when going through the look and feel of our application for a demo. I first found this value and discovered that it was different from form to form in the application. So I changed them all to the same value and checked them in to VSS. But as soon as anyone with a font that differs in size from the one used by me opens the form, the value gets corrupted. And the forms start looking different again.

The only way to ensure that you don't screw the AutoScaleBaseSize values up is if every developer uses the same dpi and font size.

My question now is... why doesn't Microsoft mention this? I haven't found any information on this subject either at MSDN or by googling. So... am I the only one to have noticed? Is everyone at Microsoft using the same font sizes, resolutions and dpi on their workstations?

Possible workaround: write an application that runs when you do a build. It scans the code for AutoScaleBaseSize and changes it across the board to one value. Or something. We are actually using the same font sizes now. That's just ridiculous.

What the HELL is wrong with Docking?
What is docking? Docking is a mechanism you can use to make controls stick to borders and edges of a form or other control. Very useful... if it had been implemented in any useful way, that is. There is an article on MSDN called Wonders of Windows Forms that explains among other things autoscaling (without bringing up the problems associated with it...) and docking. This is what they have to say on docking:
"Docking is a way to specify a specific edge that we'd like to have a control hug. For example, Figure 5 shows a form with three controls, all docked. The menu is docked to the top edge, the status bar is docked to the bottom edge, and the text box is docked to fill the rest.
The docking behavior is achieved by setting each control's Dock property to one of the values in the DockStyle enumeration."

Great. This is an article on MSDN on how to work with these things, right? Why doesn't it mention that docking is controlled by the order you add controls to a form? Or that docking more than likely will cause you headaches? Anyway, docking isn't hard, at least not when using all of three controls as they do in that article. The fact that the order you add controls to the form affects how they are displayed is more than a little absurd. The mentioning of it in the documentation only states that controls are docked in z-order, which really doesn't say how you can control the z-order of the controls (using sendtoback and bringtofront OR SetChildIndex() on the parent control). And I still get completely random behaviour when manipulating docking in run-time. Annoying.

What the HELL is wrong with the GroupBox?
This is just very strange. In the same article, mentioned above, they mention grouping of controls. This is what the starting sentence says: "The GroupBox control is one of three container controls Windows Forms provides; the other two being the Panel control and the TabControl."
Right. If these are supposed to be the grouping controls, why doesn't GroupBox have a DockPadding property? Just asking. Because those other two have it. So if I want to use DockPadding in a GroupBox (very likely scenario methinks) I have to put a Panel in it. That just sucks. This HAS to be a bug, or the worst design decision ever (well, no, not really, but it's not very logical at least). Is it by design (why?) or is it by fault?

I am going to write another post on visual inheritance, which is so bad in .NET and VS.NET that it's almost impossible to use to begin with. And I will of course ask the question needed: why doesn't MS mention the issues related to this in the articles and documentation? And why have I only found one or two articles on the subject out there? I just had to try using it to notice that the documentation was as shallow Paris Hilton and left out some things you really have to take into consideration to get what you want from visual inheritance.

My overwhelming fear is that... no one uses .NET and VS.NET to build anything serious. If they had, they would have tried to solve these issues and would have written articles about it. But I can't find any. Or is there some other angle I haven't considered? Quite possible.

What do you guys think? Am I just the embarassing person who doesn't get it or are some points valid?

Tommie Nygren
Friday, March 04, 2005

The profanity distracts from your points.

I think the Dock property is intended to be used along with the Splitter, as this article describes:

I agree that it's pretty nonintuitive, and I don't know how many levels of split you can reasonably do, but probably more than two Splitters is too many.  I also think that for what you're doing, you probably want Panel, not GroupBox.  I think (off the top of my head) that Panel is intended to be nonvisible, and only for control organization, whereas GroupBox is supposed to be a visible part of the form.

I've used inheritance of controls and inheritance of forms; the thing to remember on forms is to make the access level of the controls Protected Friend instead of just Friend.  It works, but I get a lot of weird compile errors.  I've found that if I save everything, exit, then open VS .NET back up again, those compile errors go away.  Annoying but not an unrecoverable disaster.

Friday, March 04, 2005

I am trying to do something that's almost impossible with .NET: convincing people that it's easy to deploy.

Friday, March 04, 2005

You have many valid points and I can see your frustration in the language you chose to use.  Here's the deal with window's forms in .net...

If you’re seriously going to use it in a high quality UI - don’t use most of the controls that come with the .net framework or be prepared to subclass them.  You’re frustrations are just the beginning.  Just last night I was reminded that many of the controls are just wrappers to COM controls.  When I subclassed the TextBox and found the OnPaint method never gets called, I knew it was just another wrapper.  There are work arounds though for this though.  In fact, there are a ton of work arounds!

The easy way to use windows forms is to buy a good UI suite; the hard way is to jump into the pile of crap that is System.Windows.Forms.  If you choose to jump look at the sample applications (task vision, issue vision, and photo vision) on, they have a lot of work arounds in them.

As for AutoScaleBaseSize, I’ve never had the problem you’re referring to, but I would recommend setting it after the InitializeComponent call in the form constructor.  The designer will never auto magically change it in that location.

Friday, March 04, 2005

I ran into something similar to what the OP had to deal with, moving a custom drawn form as an mdi child. Basically, you have to more or less manually do it.

I've written a more complete description of the problem and the solution on my wiki:

GD (
Saturday, March 05, 2005

> The easy way to use windows forms is to buy a good UI suite

Please recommend some (preferably several) good UI suites.

Christopher Wells
Sunday, March 06, 2005

I'm not using any suites right now, but if I were -  I'd use DotNetMagic from  They have a great demo to evaluate if their product meets your needs.

I'd stay away from infragistics, or any other company that makes EVERYTHING.  Smaller focus packages are usually better.

Hope that helps.  Sorry I couldn't provide more info.

Sunday, March 06, 2005

Has anyone tried to use the SendToBack & Bring to front methods in the IntialiseComponent method? I'm trying to auto generate forms and it doesn't look too great when they are all over the place.


Tuesday, March 08, 2005

Did you see this posting ?

Describes that very problem and suggests a few remedies.

Mr. Analogy {ISV owner}
Wednesday, March 09, 2005

I guess it depends on your definition of hard.  But it's kind of an insulting question, and sounds very naive and thus it is ironic in fact that you ask it.

The current version of the VS Designer is notoriously annoying, and we all look forward to the next, more mature release.

That being said, serious programmers working on "hard" projects can easily identify what is going wrong vis-a-vis the Designer and find the work arounds such as not using abstract base classes, etc.  They don't rely on the Designer to do everything for them.

A Serious Programmer
Friday, April 08, 2005

*  Recent Topics

*  Fog Creek Home