Ugly groupbox caption font after .NET 1.1 SP1 upgrade

[Dennis Sjogren]

Hi!

I have this medium sized solution with a couple of projects and stuff.
The generated application has an <appname>.exe.m anifest file to enable
XP themes. In the main window of the application I have several group
boxes, and even some group boxes within other group boxes.
FlatStyle=Syste m on these group boxes has always worked just fine.
Round corners on the borders and blue caption text (standard
Luna/Silver theme).

Just now, I installed .NET Framework 1.1 SP1 and all the group boxes
that were inside other group boxes has these large ugly fonts in the
caption which doesn't even fit the designated space. The group boxes
that are placed directly on the form works just fine. It's only the
ones inside other group boxes.

I've verified this on several computers. pre-SP1 works, post-SP1
doesn't. I've also created a blank project with a single form. One
group box within another group box. Same result.

Visual Studio.NET 2003 7.1.3088 (Visual Basic.NET 2003)
Windows XP Professional SP2 English
..NET Framework 1.1.4322 SP1

Has anyone else encountered this? Any recommendations on how to solve
it?

Best regards,

Dennis "Dempa" Sjogren
Dalarna University, Sweden

[Brian Henry]

This has not happened here once on any of our development systems that have
been upgraded.
"Dennis Sjogren" <la********@gma il.com> wrote in message
news:ch******** @odbk17.prod.go ogle.com...

Hi!

I have this medium sized solution with a couple of projects and stuff.
The generated application has an <appname>.exe.m anifest file to enable
XP themes. In the main window of the application I have several group
boxes, and even some group boxes within other group boxes.
FlatStyle=Syste m on these group boxes has always worked just fine.
Round corners on the borders and blue caption text (standard
Luna/Silver theme).

Just now, I installed .NET Framework 1.1 SP1 and all the group boxes
that were inside other group boxes has these large ugly fonts in the
caption which doesn't even fit the designated space. The group boxes
that are placed directly on the form works just fine. It's only the
ones inside other group boxes.

I've verified this on several computers. pre-SP1 works, post-SP1
doesn't. I've also created a blank project with a single form. One
group box within another group box. Same result.

Visual Studio.NET 2003 7.1.3088 (Visual Basic.NET 2003)
Windows XP Professional SP2 English
.NET Framework 1.1.4322 SP1

Has anyone else encountered this? Any recommendations on how to solve
it?

Best regards,

Dennis "Dempa" Sjogren
Dalarna University, Sweden

[Mick Doherty]

I can confirm that I see this too. VB Classic used to suffer from this
problem and I created a Groupbox Control specifically to overcome this.
Looks like I might have to reproduce it for .net.

Visual Styles seem to be a major problem for MS to comply with. Maybe they
should have created all new controls from scratch instead of wrapping the
old ones and then overcoming problems that they encounter. Sure it would
have meant more testing, but then they obviously don't test enough to
prevent these bugs from being reproduced anyway.

--
Mick Doherty
http://dotnetrix.co.uk/nothing.html
"Brian Henry" <br**********@n ewsgroups.nospa m> wrote in message
news:O4******** ******@TK2MSFTN GP10.phx.gbl...

This has not happened here once on any of our development systems that
have been upgraded.
"Dennis Sjogren" <la********@gma il.com> wrote in message
news:ch******** @odbk17.prod.go ogle.com...

Hi!

I have this medium sized solution with a couple of projects and stuff.
The generated application has an <appname>.exe.m anifest file to enable
XP themes. In the main window of the application I have several group
boxes, and even some group boxes within other group boxes.
FlatStyle=Syste m on these group boxes has always worked just fine.
Round corners on the borders and blue caption text (standard
Luna/Silver theme).

Just now, I installed .NET Framework 1.1 SP1 and all the group boxes
that were inside other group boxes has these large ugly fonts in the
caption which doesn't even fit the designated space. The group boxes
that are placed directly on the form works just fine. It's only the
ones inside other group boxes.

I've verified this on several computers. pre-SP1 works, post-SP1
doesn't. I've also created a blank project with a single form. One
group box within another group box. Same result.

Visual Studio.NET 2003 7.1.3088 (Visual Basic.NET 2003)
Windows XP Professional SP2 English
.NET Framework 1.1.4322 SP1

Has anyone else encountered this? Any recommendations on how to solve
it?

Best regards,

Dennis "Dempa" Sjogren
Dalarna University, Sweden

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.742 / Virus Database: 495 - Release Date: 19/08/2004

[Herfried K. Wagner [MVP]]

* "Mick Doherty" <EX***********@ AND.REMOVE.SQUA REBRACKETS.[mdaudi100#ntlwo rld.com]> scripsit:

Visual Styles seem to be a major problem for MS to comply with. Maybe they
should have created all new controls from scratch instead of wrapping the
old ones and then overcoming problems that they encounter. Sure it would
have meant more testing, but then they obviously don't test enough to
prevent these bugs from being reproduced anyway.

The support for Visual Styles in .NET 2.0 will be excellent from what
can be seen in the beta version of .NET 2.0. Most Visual Styles bugs
are fixed, and controls that currently don't support visual styles will
support them in .NET 2.0.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Mick Doherty]

"Herfried K. Wagner [MVP]" <hi************ ***@gmx.at> wrote in message
news:O5******** *******@TK2MSFT NGP14.phx.gbl.. .

The support for Visual Styles in .NET 2.0 will be excellent from what
can be seen in the beta version of .NET 2.0. Most Visual Styles bugs
are fixed, and controls that currently don't support visual styles will
support them in .NET 2.0.

.... and then there'll be a new set of bugs for which we'll have to await the
release of VS2007 and purchase another upgrade to fix existing bugs. Looks
like MS have dropped the 'Check for Updates' method in Visual studio in
favour of the 'Buy New Bugs' method.
From what I've seen of VB2005 the controls are still wrapped around the old
Common Controls and so still have a lot of problems, although there is
better support for Visual Styles.

--
Mick Doherty
http://dotnetrix.co.uk/nothing.html

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.742 / Virus Database: 495 - Release Date: 19/08/2004

[Herfried K. Wagner [MVP]]

Mick,

* "Mick Doherty" <EX***********@ AND.REMOVE.SQUA REBRACKETS.[mdaudi100#ntlwo rld.com]> scripsit:

The support for Visual Styles in .NET 2.0 will be excellent from what
can be seen in the beta version of .NET 2.0. Most Visual Styles bugs
are fixed, and controls that currently don't support visual styles will
support them in .NET 2.0.

... and then there'll be a new set of bugs for which we'll have to await the
release of VS2007 and purchase another upgrade to fix existing bugs. Looks
like MS have dropped the 'Check for Updates' method in Visual studio in
favour of the 'Buy New Bugs' method.
From what I've seen of VB2005 the controls are still wrapped around the old
Common Controls and so still have a lot of problems, although there is
better support for Visual Styles.

As long as the Windows Forms controls do not support all the
styles/behavior provided by the wrapped Common Controls, basing them on
a fully managed implementation will prevent the programmers from
extending the controls using p/invoke. Having this in mind, I think
it's better that the controls are still based on the native controls
Windows provides.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Mick Doherty]

"Herfried K. Wagner [MVP]" <hi************ ***@gmx.at> wrote in message
news:OJ******** ******@TK2MSFTN GP12.phx.gbl...

Mick,

As long as the Windows Forms controls do not support all the
styles/behavior provided by the wrapped Common Controls, basing them on
a fully managed implementation will prevent the programmers from
extending the controls using p/invoke. Having this in mind, I think
it's better that the controls are still based on the native controls
Windows provides.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Any developer using .net should not be forced to use p/invoke to extend
controls. Dotnet is not Platform Specific so we should not use Paltform
Specific API calls except to do Platform Specific Tasks.
For Visual Appearance our controls do not need to be based upon the old
Common Controls. A control derived from Control can be made to look and act
like any of the Common Controls. It is a lot of work, I'll admit, but it is
not necessary to wrap the existing controls, they can be mimicked.

VB2005 has the new MenuStrip and ToolStrip Controls which are not based upon
the old Windows Controls, but are based upon ScrollableContr ol. I personally
don't like them, but they are certainly a step in the right direction.

I am not saying that we should totally abandon the old controls, just that
they should be a second choice and not the primary choice for controls. We
can still use the old Menu and Toolbar controls in VS2005, but they are not
in the default Toolbox.

--
Mick Doherty
http://dotnetrix.co.uk/nothing.html
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.742 / Virus Database: 495 - Release Date: 19/08/2004

[Herfried K. Wagner [MVP]]

Mick,

* "Mick Doherty" <EX***********@ AND.REMOVE.SQUA REBRACKETS.[mdaudi100#ntlwo rld.com]> scripsit:

styles/behavior provided by the wrapped Common Controls, basing them on
a fully managed implementation will prevent the programmers from
extending the controls using p/invoke. Having this in mind, I think
it's better that the controls are still based on the native controls
Windows provides.
Any developer using .net should not be forced to use p/invoke to extend
controls.

Full ACK. Some times ago I added a suggestion in MSDN Product Feedback
Center to support vertical progressbars (they are supported by the
Common Controls). The answer is that this feature is postponed, which
means that it won't appear in .NET 2.0. There are many similar
samples. The style could be added easily (just one property that sets
the according style bit, a job that can be implemented in a few
minutes). As long as there is no 1:1 wrapper for the Common Controls,
changing that they are based on the Windows Common Controls would
definitely break existing code. If I write an application in .NET 2.0
and use p/invoke to make a progressbar vertical, then this code would
/break/ if in .NET 3.0 the progressbar is not based on Windows Common
Controls and there is no managed replacement for the p/invoke stuff I
have written for .NET 2.0.

There was a similar problem with Microsoft Windows Common Controls 6.0
ActiveX. This component was /not/ based on the Windows Common Controls
unlike the 5.0 version.
Dotnet is not Platform Specific so we should not use Paltform
Specific API calls except to do Platform Specific Tasks.
Windows Forms have a "Windows" in their name, so they are intended to be
Windows specific.
For Visual Appearance our controls do not need to be based upon the old
Common Controls. A control derived from Control can be made to look and act
like any of the Common Controls. It is a lot of work, I'll admit, but it is
not necessary to wrap the existing controls, they can be mimicked.
I agree again. But for the moment I'd like to see Microsoft completing
the wrappers in order to make such a switch possible in future
versions. Yes, they could have done that in .NET 2.0, but they did not.
VB2005 has the new MenuStrip and ToolStrip Controls which are not based upon
the old Windows Controls, but are based upon ScrollableContr ol. I personally
don't like them, but they are certainly a step in the right direction.
But ScrollableContr ol is based on the Windows native control management
too, isn't it?
I am not saying that we should totally abandon the old controls, just that
they should be a second choice and not the primary choice for controls. We
can still use the old Menu and Toolbar controls in VS2005, but they are not
in the default Toolbox.

ACK.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Mick Doherty]

> Windows Forms have a "Windows" in their name, so they are intended to be

Windows specific. MS Windows is the Primary Target for dotnet applications, but Windows.Forms
can be used on other Platforms. Windows is the generic name that MS use for
a base object and so Windows is the logical label for them to give the
Namespace.

But ScrollableContr ol is based on the Windows native control management
too, isn't it?

I think that this is managed by the Framework. Without the Framework,
Windows has no idea what to do with a ScrollableContr ol, whereas, a button,
for example, can be created via p/invoke and windows knows exactly what it
is. Try to use that p/invoked button on another OS and it will fail, but
ScrollableContr ol will work just fine on any compatible system with the
Framework installed.
The more releases of this development tool and framework that depend upon
the common controls, the harder it is going to be to break away from that
dependancy. When we finally do break away, the project upgrade is going to
be similar to that between VB6 and VB.net (basically a total rewrite,
especially if you're using a lot of p/invoke).

I am forever playing around with standard controls, trying to fix minor
problems, and finding more problems. Sometimes it is just easier to write
the control from scratch.

I am certainly no expert on the FrameWork or even on dotnet. There is a lot
of information out there, but I hate reading. Maybe some of my observations
are wrong, but the opinions that I express are just that, my opinions. I
must also add that I have never written an application for a non MS OS and
so I may be wrong with some of my statements.

--
Mick Doherty
http://dotnetrix.co.uk/nothing.html
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.742 / Virus Database: 495 - Release Date: 19/08/2004

[Cor Ligthert]

Mick,

I find your message has a very good point, when you want your dotNet program
to be platform independent, than you should keep yourself to the framework
and avoid any interaction with the OS direct.

Cor