您所在位置：主题：请高\手翻译下谢谢
13567696058
[专家分：0] 发布于 2006-04-20 15:46:00
Why VCL for .NET
Why VCL for .NET? - by Danny Thorpe
Abstract: Why did Borland create VCL for .NET, and when should you use it instead of .NET's own Windows Forms framework?
Delphi 8 for .NET is kicking up enormous excitement in the Delphi community! Newsgroups, chat rooms, and user group coffee klatsches are abuzz with questions about the .NET infrastructure and how it relates to the Win32 platform we're all familiar with.
One topic that has been generating a bit of heated discussion is Delphi 8's VCL for .NET. Most of the arguments seem to be over what VCL for .NET's purpose is in the grand scheme of things. Is it a short-term migration bridge or a long-term application framework? Why would Borland create something that competes with Microsoft's WinForms? "Tastes great" or "Less filling"?
Ok kids, settle down. There's no need to come to blows over this, really. Here's the story.
Background
Microsoft's .NET Framework supplies a hardware-independent execution environment and language-agnostic type system. That's great, but not enough for producing client applications for the Windows operating system. .NET also includes a Windows Forms ("WinForms") application framework for building graphical applications for the Win32 operating system. Coders familiar with Borland's VCL application framework in Delphi and C++Builder will recognize many of the design patterns in .NET's WinForms framework. That should come as no great surprise: as Anders Hejlsberg noted, "Good ideas don't just go away."
For all the similarities between VCL and WinForms, though, there are just enough core differences to make porting existing Win32 VCL applications to WinForms very difficult. Difficult means painful, and pain inhibits adoption of new ideas... as well as sales of tools to take you there.
.NET is a new platform. Even with all of the new activity now going on in .NET in the software industry, .NET application development is still just a drop in the bucket compared to existing and ongoing Win32 development. In our early inquiries to determine customer interest in the .NET platform, it was very clear that while many Borland customers had speculative interest in .NET, they could not afford to abandon everything they had invested in Win32 to start from scratch on a new .NET platform. That is still true today, and will continue to be true for many years.
It's a snap to create a WinForms application in Delphi 8 for .NET. Existing Delphi developers told us "That's great, but what do we do with all this VCL code we've built up and rely upon for our business?"
To "sweeten the deal" and make the .NET platform even more attractive to existing Delphi developers, something was needed to bridge the chasm between existing Win32 development and new .NET development. It needed to be as pure .NET as the .NET Framework itself, and it needed to provide a very high degree of compatibility with the existing Win32 VCL architecture. What Delphi for .NET needed to entice existing VCL developers was an implementation of VCL on the .NET platform.
We first considered implementing VCL on top of the WinForms framework. After a bit of research, it became clear that the same architectural differences that made it difficult to port VCL apps to WinForms would make it difficult to build a VCL layer on top of WinForms - and still function in a VCL way.
What we noticed in evaluating WinForms was that WinForms sits right on top of Win32 API calls. WinForms window classes call CreateWindow() to create Win32 window handles, they hook the Win32 WndProc to listen to window messages and fire related events within the class, and so on and so forth.
Just like VCL.
If Win32 API calls from managed .NET code are good enough for the .NET Framework, they should be good enough for VCL! The process of implementing VCL on the .NET platform then became a matter of figuring out how to make the Win32 API calls that the existing VCL architecture relies upon and make as few changes to the VCL code itself as we could manage.
Why VCL for .NET? - by Danny Thorpe
Abstract: Why did Borland create VCL for .NET, and when should you use it instead of .NET's own Windows Forms framework?
Delphi 8 for .NET is kicking up enormous excitement in the Delphi community! Newsgroups, chat rooms, and user group coffee klatsches are abuzz with questions about the .NET infrastructure and how it relates to the Win32 platform we're all familiar with.
One topic that has been generating a bit of heated discussion is Delphi 8's VCL for .NET. Most of the arguments seem to be over what VCL for .NET's purpose is in the grand scheme of things. Is it a short-term migration bridge or a long-term application framework? Why would Borland create something that competes with Microsoft's WinForms? "Tastes great" or "Less filling"?
Ok kids, settle down. There's no need to come to blows over this, really. Here's the story.
Background
Microsoft's .NET Framework supplies a hardware-independent execution environment and language-agnostic type system. That's great, but not enough for producing client applications for the Windows operating system. .NET also includes a Windows Forms ("WinForms") application framework for building graphical applications for the Win32 operating system. Coders familiar with Borland's VCL application framework in Delphi and C++Builder will recognize many of the design patterns in .NET's WinForms framework. That should come as no great surprise: as Anders Hejlsberg noted, "Good ideas don't just go away."
For all the similarities between VCL and WinForms, though, there are just enough core differences to make porting existing Win32 VCL applications to WinForms very difficult. Difficult means painful, and pain inhibits adoption of new ideas... as well as sales of tools to take you there.
.NET is a new platform. Even with all of the new activity now going on in .NET in the software industry, .NET application development is still just a drop in the bucket compared to existing and ongoing Win32 development. In our early inquiries to determine customer interest in the .NET platform, it was very clear that while many Borland customers had speculative interest in .NET, they could not afford to abandon everything they had invested in Win32 to start from scratch on a new .NET platform. That is still true today, and will continue to be true for many years.
It's a snap to create a WinForms application in Delphi 8 for .NET. Existing Delphi developers told us "That's great, but what do we do with all this VCL code we've built up and rely upon for our business?"
To "sweeten the deal" and make the .NET platform even more attractive to existing Delphi developers, something was needed to bridge the chasm between existing Win32 development and new .NET development. It needed to be as pure .NET as the .NET Framework itself, and it needed to provide a very high degree of compatibility with the existing Win32 VCL architecture. What Delphi for .NET needed to entice existing VCL developers was an implementation of VCL on the .NET platform.
We first considered implementing VCL on top of the WinForms framework. After a bit of research, it became clear that the same architectural differences that made it difficult to port VCL apps to WinForms would make it difficult to build a VCL layer on top of WinForms - and still function in a VCL way.
What we noticed in evaluating WinForms was that WinForms sits right on top of Win32 API calls. WinForms window classes call CreateWindow() to create Win32 window handles, they hook the Win32 WndProc to listen to window messages and fire related events within the class, and so on and so forth.
Just like VCL.
If Win32 API calls from managed .NET code are good enough for the .NET Framework, they should be good enough for VCL! The process of implementing VCL on the .NET platform then became a matter of figuring out how to make the Win32 API calls that the existing VCL architecture relies upon and make as few changes to the VCL code itself as we could manage.
