Ugly groupbox caption font after .NET 1.1 SP1 upgrade

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**********@newsgroups.nospam> wrote in message
news:O4**************@TK2MSFTNGP10.phx.gbl...

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

I have this medium sized solution with a couple of projects and stuff.
The generated application has an <appname>.exe.manifest 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=System 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

Nov 21 '05 #3

* "Mick Doherty" <EX***********@AND.REMOVE.SQUAREBRACKETS.[mdaudi100#ntlworld.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/>

Nov 21 '05 #4

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:O5***************@TK2MSFTNGP14.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

Nov 21 '05 #5

Mick,

* "Mick Doherty" <EX***********@AND.REMOVE.SQUAREBRACKETS.[mdaudi100#ntlworld.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/>

Nov 21 '05 #6

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:OJ**************@TK2MSFTNGP12.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 ScrollableControl. 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

Nov 21 '05 #7

Mick,

* "Mick Doherty" <EX***********@AND.REMOVE.SQUAREBRACKETS.[mdaudi100#ntlworld.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 ScrollableControl. I personally
don't like them, but they are certainly a step in the right direction.
But ScrollableControl 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/>

Nov 21 '05 #8

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

Nov 21 '05 #9

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

Nov 21 '05 #10

* "Mick Doherty" <EX***********@AND.REMOVE.SQUAREBRACKETS.[mdaudi100#ntlworld.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/frlrfSystemWindowsForms.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 ScrollableControl 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 ScrollableControl, whereas, a
button,

I remember that it's possible to subclass controls derived from
'ScrollableControl' 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
ScrollableControl 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
'ScrollableControl' 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/>

Nov 21 '05 #11

> "

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

Nov 21 '05 #12

* "Cor Ligthert" <no**********@planet.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/>

Nov 21 '05 #13

> >> 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.Windows, 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

Nov 21 '05 #14

Cor,

* "Cor Ligthert" <no**********@planet.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.Windows, 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/>

Nov 21 '05 #15

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.VisualBasic) 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

Nov 21 '05 #16

> 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/frlrfSystemWindowsForms.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.Windows). 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 ScrollableControl 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 ScrollableControl, whereas, a
button,

I remember that it's possible to subclass controls derived from
'ScrollableControl' 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.Windows 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.Windows 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

Nov 21 '05 #17

* "Cor Ligthert" <no**********@planet.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.VisualBasic) are
not 1:1 implemented than you cannot call it platform independent.

Platform independence was never a main goal for .NET. Interoperability
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/>

Nov 21 '05 #18

Mick,

* "Mick Doherty" <EX***********@AND.REMOVE.SQUAREBRACKETS.[mdaudi100#ntlworld.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/frlrfSystemWindowsForms.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/vbconintroductiontowfcforms.asp>

"
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.Windows). 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 ScrollableControl 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 ScrollableControl, whereas, a
button,

I remember that it's possible to subclass controls derived from
'ScrollableControl' 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.Windows 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.Windows 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/>

Nov 21 '05 #19

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

Nov 21 '05 #20

* "Mick Doherty" <EX***********@AND.REMOVE.SQUAREBRACKETS.[mdaudi100#ntlworld.com]> scripsit:

You obviously like to read, unlike me.
I never read a book about .NET, but I read the documentation. Sometimes
reading is necessary... though I avoid reading because it's
time-consuming.
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.

:-)

That's what we are doing here in the group day by day: Spending our
time discussing possible bugs and issues, and finding fixes and
workarounds. I would miss that too. But I agree that a completely new
set of controls that is not a wrapper around the existing common
controls would be great.

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

Nov 21 '05 #21

Corey McKinnon

"Dennis Sjogren" <la********@gmail.com> wrote in message news:<ch********@odbk17.prod.google.com>...

Hi!

I have this medium sized solution with a couple of projects and stuff.
The generated application has an <appname>.exe.manifest 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=System 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

We've also seen it here. One thing we tried was changing the
FlatStyle property from System to Standard. This fixes the problem,
but it disables the XP styling of the groupbox.

Corey

Nov 21 '05 #22

Rich Tomanio

Heres how to fix it:

Workaround 1:
Currently a workaround here is that we may put the nested child
GroupBoxes into a Panel. Since the Panel is invisible, this can have the
same visual effect.

Workaround 2:
Derive from the GroupBox class and override its WndProc function to
process the ¡°WM_PRINTCLIENT¡± message correctly:

//Please add the following using statement:
using System.Runtime.InteropServices;

public class FixedGroupBox : GroupBox
{
[DllImport("User32.dll", ExactSpelling = true, CharSet =
CharSet.Auto)]
public static extern bool GetClientRect(HandleRef hWnd, [In,
Out] ref RECT
rect);
private const int WM_PRINTCLIENT = 0x0318;
[StructLayout(LayoutKind.Sequential)]
public struct RECT
{
public int left;
public int top;
public int right;
public int bottom;
public RECT(int left, int top, int right, int bottom)
{
this.left = left;
this.top = top;
this.right = right;
this.bottom = bottom;
}
public RECT(System.Drawing.Rectangle r)
{
this.left = r.Left;
this.top = r.Top;
this.right = r.Right;
this.bottom = r.Bottom;
}
public static RECT FromXYWH(int x, int y, int width, int
height)
{
return new RECT(x, y, x + width, y + height);
}
public System.Drawing.Size Size
{
get
{
return new
System.Drawing.Size(this.right - this.left, this.bottom - this.top);
}
}
}
private void WmPrintClient(ref Message m)
{
RECT rect = new RECT();
GetClientRect(new HandleRef(this, Handle), ref rect);
Graphics graphics = Graphics.FromHdc(m.WParam);
Brush b = new SolidBrush(BackColor);
graphics.FillRectangle(b, rect.left, rect.top,
rect.right - rect.left, rect.bottom - rect.top);
graphics.Dispose();
b.Dispose();
m.Result = (IntPtr)1;
}
protected override void WndProc(ref Message m)
{
switch (m.Msg)
{
case WM_PRINTCLIENT:
WmPrintClient(ref m);
break;
default:
base.WndProc(ref m);
break;
}
}
}

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Nov 21 '05 #23