From the August 2002 issue of MSDN Magazine
|
#using <System.Dll>
#using <System.Web.dll>
using namespace System;
using namespace System::Web;
using namespace System::Web::UI;
using namespace
System::Web::UI::WebControls;
using namespace System::Collections;
using namespace System::ComponentModel;
Note that the syntax for declaring which namespaces to use follows the standard C++ scoping syntax. The heart of the code-behind module is a class that derives from System.Web.UI.Page. I'll take a look at that now.
The Page Class
Figure 4 shows the C++ code describing the code-behind page. While the code in Figure 4 looks mostly like regular C++, it differs in several significant ways. First, notice that the ManagedCWebPage class has a public modifier preceding it. The CLR enforces visibility at the module level—not just at the class member level as in basic C++. Putting the public keyword before the ManagedCWebPage class declaration causes the whole class to be visible outside the assembly. This is important because the ASPX page will need to be able to access the ManagedCWebPage class.
There's a key symbol called __gc immediately preceding the class keyword, which tells the C++ compiler that the ManagedCWebPage class is to be garbage collected. That is, instances of ManagedCWebPage will be managed by the runtime.
The rest of the C++ syntax should look pretty familiar. The ASPX page defines a button, dropdown list, label, and textbox. The programmatic counterparts to each of these elements are defined as member variables near the top of the class. If you've been writing a lot of C# code lately, you may be surprised that the member variables representing the controls are declared as pointers in this C++ code. The C++ syntax only understands the managed types when they're declared as pointers. Remember, C# doesn't have the natural pointer syntax that C++ does.
The ManagedCWebForm class implements a couple of event handlers: one for the Page_Load event and one for the SubmitEntry event (when the user presses the SubmitEntry button). The Page_Load event is called every time a client posts to the server. The System.Web.UI.Page class includes the member property IsPostBack for determining if the session is new or existing. If IsPostBack is true, then the user is posting back during an existing session. Otherwise, it's a new session. SubmitEntry extracts the name of the user from the textbox, the item selected from the dropdown list, and sets the Text field of the Label control accordingly. The syntax for each of these methods appears similar to the syntax you would see in equivalent C# code. Notice the arguments are passed as pointers. That's because the Object and EventArgs parameters are managed types.
To get the page working, just build the assembly and make sure the assembly lands in the \bin directory under the virtual directory containing the ASPX code.
Conclusion
If you're an experienced ASP developer accustomed to writing COM code to get your pages working, the CLR offers a breath of fresh air. Because all the code living under the CLR automatically agrees upon such issues as data typing, parameter order on the stack, and where to find method signatures within code (it's all described within the metadata), all the old boundary issues that COM was designed to solve disappear.
To create code that runs under the CLR, you simply need a compiler that will generate Microsoft intermediate language (MSIL), for instance C# and Visual Basic .NET. Most developers currently using Visual Basic will probably stick with Visual Basic .NET. C# offers a great curly-brace syntax for producing MSIL, and many developers are becoming enamored of C# syntax. So why would you use C++?
There are several reasons. First, you may have a huge amount of working legacy C++ code. In some cases it may be much easier to compile your DLLs as Managed C++ assemblies. For example, you might have code that represents particularly obfuscated logic that you have to keep running in your system. Another reason is that you just may not be ready to make the jump to C#. By and large, C# represents a cleaner syntax than C++ does; for example, it doesn't have any funny pointer syntax. However, C# does take a little bit of getting used to. The final, and perhaps most compelling reason to use Managed C++, is that the Microsoft C++ compiler is optimized. It's the most evolved and best-tuned compiler available for generating code to run under the CLR.
This month I looked at what it takes to write a code-behind page in Managed C++. In later columns I'll revisit the topic of using Managed C++ in other parts of an ASP.NET page.
Send questions and comments for George to asp-net@microsoft.com.. |
George Shepherd writes .NET development tools with SyncFusion. He teaches short courses with DevelopMentor and is the author of a number of programming titles, including Applied .NET (Addison-Wesley, 2001). George may be reached at georges@syncfusion.com. |