E
Ernst Raedecker
Hello all,
Finally I have decided to write about a bug in the winforms engine
that has been nagging me since the early days of the NET 1.0 betas. It
showed up in the final NET 1.0 release, in the service packs, in NET
1.1 and its service packs. And unbelievably but true it's still there
in NET 2.0, CLEARLY visible for everyone who wants to see it.
If a Windows Form contains a MainMenu then the Height of the first
instance of the form will be 1 pixel short, while the next instances
will all have an excess height of 18 pixels. The difference, 19
pixels, is related to the standard height of a menu bar.
The bug exists even in NET 2.0 when you drag a MainMenu to the form.
This happens in Windows 2000, Windows XP and Windows 2003.
The new MenuStrip of NET 2.0 does NOT contain the bug.
Let's reproduce the problem:
1. Create a new windows project with one form. Name the form class
FormSize. Add a using System.Diagnostics; line.
2. In the property box, give the form the following properties:
Location = 80,80
Size = 200,200
Startposition = Manual
3. Drag a MainMenu to the form. Create an item File on the menu and a
subitem OpenForm.
4. Doubleclick on OpenForm and enter the following code:
FormSize frm = new FormSize();
frm.Location = new Point(this.Left + this.Width, this.Top);
frm.Show();
5. In the Form_Load and Form_Activate events enter the following code:
Debug.WriteLine("Form: Height=" + this.Height + ", Width=" +
this.Width);
6. Compile and run the program with F5.
You will discover that your form has a Width = 200 and a Height = 199.
So one pixel short.
Now click on you menuitem OpenForm. A second instance of your form
will appear next to the first one. This second form has a Width = 200
and a height = 218. So 19 pixels HIGHER than the first form. The
standard menu bar has a height of 19 pixels and that accounts for the
difference.
Easiest workaround:
add the following statement to Form_Load:
this.Size = new Size(200, 200);
If you look at the generated code you will discover that the Size
property in the property box is a so-called shadow property: from its
value a ClientSize value will be calculated and this appears in the
generated code. To complicate matters further the form DOES have a
Size property, but this one is unrelated to the pseudo-Size property
in the property box.
I have no problem with the forms engine calculating a ClientSize from
my property box pseudo-Size property. I have problems with the outcome
of the calculation being wrong in runtime.
THIS BUG IS NOT AT ALL 'ELUSIVE'. In fact it is glaring, VERY visible
and VERY easy to reproduce.
However, you will find NO MENTION AT ALL of this glaring bug in the
Microsoft knowledge base. If you speak to Microsoft officials (I work
for a Microsoft Gold Partner in Holland and we have regular contacts
with Microsoft representatives) they invariably have NEVER heard of
this glaring bug. You won't find it on the internet, except perhaps in
some elusive posting of years ago.
I cannot understand that this bug has been going unnoticed for so many
years.
It seems that nobody in the world has ever used a dotnet Windows Form
application with a menu bar at the top in a real world application.
Otherwise surely people SHOULD have noticed that ALL their forms are
at least one pixel off. Yes sir, ALL your forms with a MainMenu are at
least one pixel off.
I hope that this time SOMEONE at Microsoft takes notice of this
problem, tries to reproduce it and tries to explain to me how on earth
such a visible bug has gone unnoticed for so many years. Do they
really TEST their software in America?
In Holland we programmers have the following saying for American
software: "It compiles, so it's ready. Let's sell it"
I also hope that you understand first THAT I am very annoyed and
second WHY I am very annoyed and irritated.
You see, what will happen if you show this bug to managers of, say,
big financial companies & banks and tell them that the next version of
their critical software will be using this framework. Ah, we were
three digits off in the bank account number, so the deposit went to
the wrong customer, but who cares?
How trustworthy is the software if even such visible bugs go
unnoticed? How about the bugs that are NOT so easy to notice?
Ernesto.
"You don't have to learn science if you don't feel
like it. So you can forget the whole business if
it is too much mental strain, which it usually is."
Richard Feynman
Finally I have decided to write about a bug in the winforms engine
that has been nagging me since the early days of the NET 1.0 betas. It
showed up in the final NET 1.0 release, in the service packs, in NET
1.1 and its service packs. And unbelievably but true it's still there
in NET 2.0, CLEARLY visible for everyone who wants to see it.
If a Windows Form contains a MainMenu then the Height of the first
instance of the form will be 1 pixel short, while the next instances
will all have an excess height of 18 pixels. The difference, 19
pixels, is related to the standard height of a menu bar.
The bug exists even in NET 2.0 when you drag a MainMenu to the form.
This happens in Windows 2000, Windows XP and Windows 2003.
The new MenuStrip of NET 2.0 does NOT contain the bug.
Let's reproduce the problem:
1. Create a new windows project with one form. Name the form class
FormSize. Add a using System.Diagnostics; line.
2. In the property box, give the form the following properties:
Location = 80,80
Size = 200,200
Startposition = Manual
3. Drag a MainMenu to the form. Create an item File on the menu and a
subitem OpenForm.
4. Doubleclick on OpenForm and enter the following code:
FormSize frm = new FormSize();
frm.Location = new Point(this.Left + this.Width, this.Top);
frm.Show();
5. In the Form_Load and Form_Activate events enter the following code:
Debug.WriteLine("Form: Height=" + this.Height + ", Width=" +
this.Width);
6. Compile and run the program with F5.
You will discover that your form has a Width = 200 and a Height = 199.
So one pixel short.
Now click on you menuitem OpenForm. A second instance of your form
will appear next to the first one. This second form has a Width = 200
and a height = 218. So 19 pixels HIGHER than the first form. The
standard menu bar has a height of 19 pixels and that accounts for the
difference.
Easiest workaround:
add the following statement to Form_Load:
this.Size = new Size(200, 200);
If you look at the generated code you will discover that the Size
property in the property box is a so-called shadow property: from its
value a ClientSize value will be calculated and this appears in the
generated code. To complicate matters further the form DOES have a
Size property, but this one is unrelated to the pseudo-Size property
in the property box.
I have no problem with the forms engine calculating a ClientSize from
my property box pseudo-Size property. I have problems with the outcome
of the calculation being wrong in runtime.
THIS BUG IS NOT AT ALL 'ELUSIVE'. In fact it is glaring, VERY visible
and VERY easy to reproduce.
However, you will find NO MENTION AT ALL of this glaring bug in the
Microsoft knowledge base. If you speak to Microsoft officials (I work
for a Microsoft Gold Partner in Holland and we have regular contacts
with Microsoft representatives) they invariably have NEVER heard of
this glaring bug. You won't find it on the internet, except perhaps in
some elusive posting of years ago.
I cannot understand that this bug has been going unnoticed for so many
years.
It seems that nobody in the world has ever used a dotnet Windows Form
application with a menu bar at the top in a real world application.
Otherwise surely people SHOULD have noticed that ALL their forms are
at least one pixel off. Yes sir, ALL your forms with a MainMenu are at
least one pixel off.
I hope that this time SOMEONE at Microsoft takes notice of this
problem, tries to reproduce it and tries to explain to me how on earth
such a visible bug has gone unnoticed for so many years. Do they
really TEST their software in America?
In Holland we programmers have the following saying for American
software: "It compiles, so it's ready. Let's sell it"
I also hope that you understand first THAT I am very annoyed and
second WHY I am very annoyed and irritated.
You see, what will happen if you show this bug to managers of, say,
big financial companies & banks and tell them that the next version of
their critical software will be using this framework. Ah, we were
three digits off in the bank account number, so the deposit went to
the wrong customer, but who cares?
How trustworthy is the software if even such visible bugs go
unnoticed? How about the bugs that are NOT so easy to notice?
Ernesto.
"You don't have to learn science if you don't feel
like it. So you can forget the whole business if
it is too much mental strain, which it usually is."
Richard Feynman