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

[Herfried K. Wagner [MVP]]

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

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.

Let's see what this document says:

..NET Framework Class Library -- 'System.Windows .Forms' Namespace
<URL:http://msdn.microsoft. com/library/en-us/cpref/html/frlrfSystemWind owsForms.asp>

"
The 'System.Windows .Forms' namespace contains classes for creating
Windows-based applications that take full advantage of the rich user
interface features available in the Microsoft Windows operating system.
"

For me, this means that the Windows Forms classes are intended to be for
use with Windows only, and they are designed having Windows'
characteristics in mind.

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,

I remember that it's possible to subclass controls derived from
'ScrollableCont rol' for 'WM_HSCROLL' and 'WM_VSCROLL', at least in .NET
1.0/1.1. Consequently this control is only sort of wrapper too, or at
least heavily based on Windows's controls.

A fully managed implementation of the Windows Forms package would be the
best solution to provide a solid roadmap on Windows' controls. As long
as Windows Forms are only a wrapper around Windows' controls, every
extension (except what's possible in ownerdrawn modes) must be made in
the underlying Windows controls before being introduced in the .NET
Framework's Windows Forms. On the other hand, if the .NET Framework
bases its implementation on the native Windows controls and Common
Controls, extensions only made in the .NET Framework won't be accessible
by unmanaged applications.
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.
I didn't dig deeper into this issue, but I thinl that even
'ScrollableCont rol' needs to be reimplemented on each target operating
system/window system.

Basing all controls on a fully managed Windows Forms package would be
great, but it would mean that everything that is currently implemented
in the native Windows controls package (such as hit-testing, painting,
....) needs to be reimplemented in a managed way.
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).
It's a sad thought, but I fear that the switch to the "next generation"
of a .NET forms package will make all code obsolete and almost
everything needs to be rewritten.
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.

:-)

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

[Cor Ligthert]

> "

The 'System.Windows .Forms' namespace contains classes for creating
Windows-based applications that take full advantage of the rich user
interface features available in the Microsoft Windows operating system.
"

Yes this can be said by Mono as well, when they say the same, however than
with Linux.

However when you are creating Platform independent programs you have to
create that for the top layer, not something in between or even deeper.

This will be not the last time in this history, that a good idea is spoiled
because people started to use faster and nicer routines dependable on the
platform.

Cor

[Herfried K. Wagner [MVP]]

* "Cor Ligthert" <no**********@p lanet.nl> scripsit:

"
The 'System.Windows .Forms' namespace contains classes for creating
Windows-based applications that take full advantage of the rich user
interface features available in the Microsoft Windows operating system.
"

Yes this can be said by Mono as well, when they say the same, however than
with Linux.

It's Microsoft who invented 'System.Windows .Forms'. It's a
Windows-specific and Windows-focussed API. If another manufacturer
implements this proprietary API (notice that 'System.Windows .Forms' is
not standardized by any standardization body) for his platform, this
doesn't mean that the statements made on the API made by the inventor
don't apply to this original implementation. BTW: There may be legal
issues if Mono or another manufacturer implements this proprietary API.

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

[Cor Ligthert]

> >> The 'System.Windows .Forms' namespace contains classes for creating

Windows-based applications that take full advantage of the rich user
interface features available in the Microsoft Windows operating system.
"

Yes this can be said by Mono as well, when they say the same, however than with Linux.

It's Microsoft who invented 'System.Windows .Forms'. It's a
Windows-specific and Windows-focussed API. If another manufacturer
implements this proprietary API (notice that 'System.Windows .Forms' is
not standardized by any standardization body) for his platform, this
doesn't mean that the statements made on the API made by the inventor
don't apply to this original implementation. BTW: There may be legal
issues if Mono or another manufacturer implements this proprietary API

Maybe I am not writing this theoretical right, however I assume you can
understand what I mean. System.Windows. Forms is a namespace used in VBNet.

That means that the ones who want to make a VBNet compatible compiler, has
to implement that.

That he than uses an "interface" to his own API or whatever name you can use
for that, is obvious, however probably that will not act the same as an API
to Microsoft.Windo ws, because that is to another OS.

That should not mean you cannot use it, however it is probably not anymore
platform independent.

Just my thought,

Cor

[Herfried K. Wagner [MVP]]

Cor,

* "Cor Ligthert" <no**********@p lanet.nl> scripsit:

The 'System.Windows .Forms' namespace contains classes for creating
Windows-based applications that take full advantage of the rich user
interface features available in the Microsoft Windows operating system.
"

Yes this can be said by Mono as well, when they say the same, however than
with Linux.
It's Microsoft who invented 'System.Windows .Forms'. It's a
Windows-specific and Windows-focussed API. If another manufacturer
implements this proprietary API (notice that 'System.Windows .Forms' is
not standardized by any standardization body) for his platform, this
doesn't mean that the statements made on the API made by the inventor
don't apply to this original implementation. BTW: There may be legal
issues if Mono or another manufacturer implements this proprietary API

Maybe I am not writing this theoretical right, however I assume you can
understand what I mean. System.Windows. Forms is a namespace used in VBNet.

I think I understand what you mean.
That means that the ones who want to make a VBNet compatible compiler, has
to implement that.
I don't agree with this. Windows Forms are an additional library to the
base class library. If you take a look at
<URL:http://www.go-mono.com/docs/> you will see that there are several
managed libraries that are not part of Microsoft's implementation of the
..NET Framework, for example, the Gnome library. This doesn't mean that
Microsoft has to implement this library.

The BCL is standardized, and is a smallest common set of classes that is
required to build .NET applications. This doesn't include UI packages
like Windows Forms (made by Microsoft), the Gnome library (made by
mono(?)), ...
That he than uses an "interface" to his own API or whatever name you can use
for that, is obvious, however probably that will not act the same as an API
to Microsoft.Windo ws, because that is to another OS.

There /can/ be another implementation of the Windows Forms package. But
Windows Forms also includes classes like 'NativeWindow',
'MessageFilter' , and so on, which are highly Windows-specific and
sometimes hard to implement on other platforms without actually
"copying" Windows.

In other words, Windows forms will IMO never become a platform
independent solution for building rich UI applications. There are
packages like GTK# available which were designed as platform independent
UI libraries.

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

[Cor Ligthert]

In other words, Windows forms will IMO never become a platform
independent solution for building rich UI applications. There are
packages like GTK# available which were designed as platform independent
UI libraries.

When the classes of Net (inclusief at the moment Microsoft.Visua lBasic) are
not 1:1 implemented than you cannot call it platform independent. With that
not saying you are not right about the use at the moment, however when it
will be platform independent than it should be the same in my opinion.
Otherwise you can name it a lookalike.

(And I am definitly not talking about windows, which has a form Api, however
a lot more)

However again just my thought,

Cor

[Mick Doherty]

> Let's see what this document says:

.NET Framework Class Library -- 'System.Windows .Forms' Namespace
<URL:http://msdn.microsoft. com/library/en-us/cpref/html/frlrfSystemWind owsForms.asp>

"
The 'System.Windows .Forms' namespace contains classes for creating
Windows-based applications that take full advantage of the rich user
interface features available in the Microsoft Windows operating system.
"

For me, this means that the Windows Forms classes are intended to be for
use with Windows only, and they are designed having Windows'
characteristics in mind.

I read it differently. For me Windows is the Generic term that MS use for
the base object. They have created a Namespace 'System.Windows ' (not
Microsoft.Windo ws). The classes in this Namespace are written to be fully
compatible with the Microsoft Windows operating system and this is their
Primary Target. They are, however, totally independent of Microsoft Windows
and can function on other Platforms. If they were not intended to be used on
other compatible OS's then why recreate the already well defined Window
Class?

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,

I remember that it's possible to subclass controls derived from
'ScrollableCont rol' for 'WM_HSCROLL' and 'WM_VSCROLL', at least in .NET
1.0/1.1. Consequently this control is only sort of wrapper too, or at
least heavily based on Windows's controls.

Again, to me this means that it fully supports the existing
Microsoft.Windo ws Message structure, which I would expect it to do.

---- Useless analogy -----------------------------------------------------
I can sit on a chair or I can sit on the floor. The fact that I can perform
this same operation on both of them does not make them related in any way.
--------------------------------------------------------------------------

As I understand it, the Framework Messaging system uses the same messages
that Microsoft.Windo ws uses, so If I want to Paint a Window I would send a
WM_PAINT message to it and because the Framework understands this message it
will carry out the correct procedure regardless of the OS. MS Windows
operating systems may have an advantage because the OS itself understands
this message and does not need the framework to interpret it.

--
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]]

* "Cor Ligthert" <no**********@p lanet.nl> scripsit:

In other words, Windows forms will IMO never become a platform
independent solution for building rich UI applications. There are
packages like GTK# available which were designed as platform independent
UI libraries.
When the classes of Net (inclusief at the moment Microsoft.Visua lBasic) are
not 1:1 implemented than you cannot call it platform independent.

Platform independence was never a main goal for .NET. Interoperabilit y
and device independence (full framework vs. Compact Framework) were the
most important design goals.
With that not saying you are not right about the use at the moment,
however when it will be platform independent than it should be the
same in my opinion.

Microsoft AFAIK has never planned to make all parts of .NET platform
independent and provides implementations for Windows only. There are no
plans to target other platforms, AFAIK. The core of .NET is
standardized to enable other companies to implement this part. The rest
is proprietary and will stay proprietary for the near future.

The standardization is on runtime level (execution engine, CLR, core
framework), and not primarily on library level. There will be an
increasing number of platform-specific APIs, like Avalon in the near
future, for example, and also lots of such APIs provided by other
companies.

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

[Herfried K. Wagner [MVP]]

Mick,

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

Let's see what this document says:

.NET Framework Class Library -- 'System.Windows .Forms' Namespace
<URL:http://msdn.microsoft. com/library/en-us/cpref/html/frlrfSystemWind owsForms.asp>

"
The 'System.Windows .Forms' namespace contains classes for creating
Windows-based applications that take full advantage of the rich user
interface features available in the Microsoft Windows operating system.
"

For me, this means that the Windows Forms classes are intended to be for
use with Windows only, and they are designed having Windows'
characteristics in mind.
I read it differently. For me Windows is the Generic term that MS use for
the base object.

Windows in proper case is referring to the Windows operating system. If
windows is written in small letters it's referring to windows in
general. "Windows-based" means applications "based on Microsoft
Windows", or "for the Microsoft Windows operating system".

Another document:

Visual Studio -- Introduction to Windows Forms
<URL:http://msdn.microsoft. com/library/en-us/vbcon/html/vbconintroducti ontowfcforms.as p>

"
Windows Forms is the new platform for Microsoft Windows application
development, based on the .NET Framework. This framework provides a
clear, object-oriented, extensible set of classes that enable you to
develop rich Windows applications.
"
They have created a Namespace 'System.Windows ' (not
Microsoft.Windo ws). The classes in this Namespace are written to be fully
compatible with the Microsoft Windows operating system and this is their
Primary Target. They are, however, totally independent of Microsoft Windows
and can function on other Platforms. If they were not intended to be used on
other compatible OS's then why recreate the already well defined Window
Class?
The .NET Windows Forms API is heavily based on the native control/UI
libraries included in Microsoft windows. In fact, they are a very thin
wrapper around these controls. 'NativeWindow' is very low-level, it is
attached to window handles, it works with messages defined for Windows,
that are not even defined in an enum or similar for the managed wrapper
around the native Windows Forms.

If you listen for a certain message in a form's 'WndProc', this is fully
managed code. But you'll have to know the /value/ of the message you
are listening for. There are no named constants, there is no "safety"
in matters of which message number belongs to which window message.
This is not very portable by design. There was no intention to choose a
portable design, otherwise Microsoft would have written a more
high-level wrapper that makes the underlying Windows' native controls
management completely transparent to the user of the library.

The reason why Microsoft has decided to write a wrapper around Windows'
controls is that there needed to be a replacement for VB6's form package
and WTL/MFC. If there was no such replacement present, no VB6
programmer would have turned to VB.NET. Providing a managed interface
also allowed a smooth integration of Windows' UI capabilities into .NET
applications without dealing with unmanaged code except in some rare
cases.

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,

I remember that it's possible to subclass controls derived from
'ScrollableCont rol' for 'WM_HSCROLL' and 'WM_VSCROLL', at least in .NET
1.0/1.1. Consequently this control is only sort of wrapper too, or at
least heavily based on Windows's controls.

Again, to me this means that it fully supports the existing
Microsoft.Windo ws Message structure, which I would expect it to do.

Take the Spy++ tool and take a look at a picturebox, for example.
That's actually a native Windows control (OK, they have created their
own window class, but it's a Windows control, not a .NET control).

To make a conclusion: Yes, Windows Forms is portable if you port the
(unmanaged) native Windows control and Common Controls APIs too.
---- Useless analogy -----------------------------------------------------
I can sit on a chair or I can sit on the floor. The fact that I can perform
this same operation on both of them does not make them related in any way.
--------------------------------------------------------------------------
In the particular case we are discussing, this analogy IMO doesn't fully
fit. It's not just the same appearance of the message system inside
..NET, but also other (unmanaged) Windows applications can manipulate the
windows created with .NET Windows Forms using p/invoke. This would not
be possible if they didn't have the same foundation. Windows handles
are unique system wide, .NET Windows Forms doesn't start its Windows
handles by its own origin, 1 for example, even if already an
unmanaged window created by an unmanaged application exists.
As I understand it, the Framework Messaging system uses the same messages
that Microsoft.Windo ws uses, so If I want to Paint a Window I would send a
WM_PAINT message to it and because the Framework understands this message it
will carry out the correct procedure regardless of the OS.
IMHO these messages are all defined/handled in unmanaged code that is
wrapped by the Windows Forms library. There is no complete managed
replacement of Windows' UI infrastructure inside .NET.
MS Windows operating systems may have an advantage because the OS
itself understands this message and does not need the framework to
interpret it.

Yep -- that's not yet implemented in Microsoft's implementation of
Windows Forms, and I doubt that there will ever be an alternative
managed implementation to the unmanaged native implementation the
current version of Windows Forms is based on.

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

[Mick Doherty]

You obviously like to read, unlike me.
Maybe my theory is the way I would like the Framework to work. If the
framework did all of the work then I could write one application which would
run on both Windows and Linux without me having to know the specifics of
both OS's.

---- Useless
analogy -----------------------------------------------------
I can sit on a chair or I can sit on the floor. The fact that I can
perform
this same operation on both of them does not make them related in any
way.
--------------------------------------------------------------------------

In the particular case we are discussing, this analogy IMO doesn't fully
fit.

I did give it the title 'Useless analogy' ;-)

I would still like to see a completely new set of controls to replace the
existing wrapped common controls, but then I guess that's what third party
control suites are for. If off the shelf controls worked as expected then I
would probably be bored with programming anyway, since I spend most of my
time playing with broken controls.

--
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