Mick,
* "Mick Doherty" <EXCHANGE#
[email protected].[mdaudi100#ntlworld.com]> scripsit:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
LOL!
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.
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.