Programming for Windows Forms with Managed Extensions for C + +

Summary: This article discusses how to use Visual C + +. NET Managed Extensions for Windows Forms programming and provides examples of manual programming techniques that use direct access to Windows Forms classes, as well as examples of using the Windows Forms Designer. In addition, this article compares Windows forms with Microsoft base class (MFC) applications.

Brief introduction

Programmers have long used C and C + + to develop their Windows GUI applications. For many of us, this history dates back to Windows 2.0, when we used the 16-bit Windows API based on C to write dozens of lines of code even if only one window was displayed. Fortunately, as time goes on, the level of abstraction is getting higher and better. In 1992, Microsoft released the programmer ' s Workbench, which includes Microsoft Foundation Class Library version 1.0. The Microsoft Foundation Class Library version 1.0 contains approximately 60 classes for the 16-bit Windows API for wrapping windowed programming and drawing sections. By 2002, Microsoft Foundation Class Library version 7.0 had grown to more than 200 classes, and its purpose had been expanded to provide a complete C + + object model substitute for the Microsoft Win32 API.

Although MFC is very powerful, but it also has a lot of shortcomings, such as it is only a thin layer of Win32 outside the API, and for many programmers, it is too complex, it is difficult to use effectively. In general, to develop Windows applications, you still need to access the Win32 APIs directly, especially in the context of a growing demand for the basic functionality required by Windows applications. Therefore, it takes a lot of time and effort to develop any truly powerful Windows GUI applications. In response to the growing difficulty of application development, Microsoft released a new programming environment for the Windows platform in early 2002. This environment is called the. NET Framework, it provides developers with a managed application runtime and a large number of libraries called. NET Framework class libraries. The. NET Framework can manage memory and security to produce more reliable applications. The. NET Framework class library provides a large, resource-rich, and unified class library, Any. NET language, including Managed Extensions for C + + and C + + hosted by Micrisoft for. NET programmers, can access the class library equally in the same way. As part of the. NET Framework, Windows Forms is a set of classes for building client Windows GUI applications.

In this article, we'll delve into how to write Windows forms code using Managed Extensions for C + +, first on how to start from scratch, and then explain how to do this with Microsoft Visual Studio. NET 2003来. At the same time, we will focus on some common features of Windows forms, such as automatic layout and data binding. Finally, we'll focus on comparing Windows forms to MFC and how to mix the two sets of tools when using Managed Extensions further.

What is a Windows form?

Windows Forms is a windowing toolkit, not a complete application framework like MFC. In fact, MFC provides more functionality than the functionality provided by Windows forms for building a document-independent application. For example, if you want to build a text editor, in MFC, simply run a wizard, select the appropriate options, and write several lines of code to complete. The only application you get from running the wizard contains a status bar, a toolbar (floating), and all of the file, Edit, and Help menu items, including the list of recently used files and print and context-sensitive assistance. All of this content is included in a fully-logo-compliant single Document interface (SDI), multiple SDI, or multiple document interface (MDI) application. As a document-based application framework, there are no competitors that can match MFC.

However, programmers now tend to build more html-based applications, or applications that can communicate with business objects or database servers, rather than document based applications. The. NET framework and Windows forms are tailored for this purpose.

This is not to say that Windows forms cannot be used to build excellent document-based applications. In fact, because Windows Forms are only a small part of the more than 2000 classes provided by the. NET Framework, what you need is most likely that Windows Forms are not available, but are located in other parts of the framework. For example, the Windows forms themselves do not provide any object serialization support, but the remainder of the. NET Framework class Library provides a variety of methods for serializing object graphs.

This is the main difference between MFC and Windows forms. MFC is designed to replace the underlying WIN32 API, but this does not prevent the Win32 API from growing. In fact, just as MFC has grown over time, the underlying OS has been at least 10 times times more functional. However, Windows Forms is just a substitute for the Win32 part of the. NET Framework class, which replaces the rest of the Win32. Of course, the framework will never replace the entire Win32 API, but because most new features to be added to Windows are added to the framework in the foreseeable future, replacing the entire WIN32 API will be a future goal.

Therefore, although Windows forms cannot have all of the functionality of MFC, it does provide a powerful set of features that can greatly facilitate client application developers, including some features that are completely out of MFC. Next, we'll cover how to build the application from scratch, and then explain the productivity enhancements that Visual Studio. NET 2003 provides for Windows forms C + + programmers.

Create a Windows form from scratch

A typical Windows forms application has at least one form. A form is a window, which is the Microsoft user interface unit that we've seen starting with Windows 1.0. Typically, a form in a Windows forms application is the main form, meaning that it is the parent or owner of all other forms that may appear during the life cycle of the application. The form is where you display the main menu, as well as toolbars, taskbar, and so on. The application also exits when the main form ends.

The main form of an application can be a simple message box, a dialog box, an SDI window, an MDI window, or a more complex control, such as a form with multiple child windows, tool windows, and floating toolbars in an application like Visual Studio. NET.

If your application is extremely simple, you can implement it using a simple message box that is flooded with any windowing system:

#using <mscorlib.dll>
#using <System.dll>
#using <System.Windows.Forms.dll>
void __stdcall WinMain(HINSTANCE hInstance,
　　　　　　 HINSTANCE hPrevInstance,
　　　　　long lpCmdLine,
　　　　　int nCmdShow)
{
　System::Windows::Forms::MessageBox::Show("Hello, Windows Forms");
}

As a C + + programmer, you must be very familiar with the WinMain entry point, and you still need that entry point in your managed application. In our first Windows forms application, the only actual line of code that calls the static Show method of the Windows::system::forms::messagebox class is actually just the call contained in Window::systems: The long write form of the static method of the MessageBox class within the forms namespace. Namespaces are widely used in the. NET Framework class libraries to separate classes, structs, enumerations, and other types of logical groups. This separation is necessary because thousands of Microsoft employees are working to add the. NET Framework class Library, and hundreds of third-party organizations want to extend the class library, and millions of programmers are trying to learn it. Without namespaces, complex conventions are required to uniquely name various objects (like the existing Win32 API).

The definition of a type in a namespace is in a. NET assembly. An assembly is a container for a managed type packaged as a DLL or EXE. #using directives are used to apply types in an assembly to your application. For example, the mscorlib and System assemblies provide basic. NET framework types, such as int and string. The System.Windows.Forms assembly contains Windows form types.

When you apply an assembly to an application by using #using, you can reference the type in the long write form mentioned earlier, or you can omit the work of typing code by using the standard C + + using namespace statement:

#using <mscorlib.dll>
#using <System.Windows.Forms.dll>
using namespace System::Windows::Forms;
void __stdcall WinMain(HINSTANCE hInstance,
　　　　　　 HINSTANCE hPrevInstance,
　　　　　long lpCmdLine,
　　　　　int nCmdShow)
{
　MessageBox::Show("Hello, Windows Forms");
}

Thus, while this simple example is an effective demonstration of the concept of the most basic. NET framework and Managed Extensions for C + +, it does not well demonstrate typical Windows forms programs. For real applications, you will need an instance of a form class (or a class derived from form), as follows:

void __stdcall WinMain(HINSTANCE hInstance,
　　　　　　 HINSTANCE hPrevInstance,
　　　　　long lpCmdLine,
　　　　　int nCmdShow)
{
　Form* form = new Form();
　...
}

A form variable refers to an instance of a managed type. Managed objects are handled by the common language runtime (CLR) of the. NET framework, and their lifetime is controlled by the garbage collector, which cancels allocating memory at a certain time. As a result, C + + programmers do not have to explicitly delete managed types, but they cannot expect to destroy objects at any given time, such as when closing a range.

When you create a form, you need to display it. If you've ever seen a document of a Windows form, you may have noticed the form method show, which means:

void __stdcall WinMain(HINSTANCE hInstance,
　　　　　　 HINSTANCE hPrevInstance,
　　　　　long lpCmdLine,
　　　　　int nCmdShow)
{
　Form* form = new Form();
　form->Show(); // This is not what you want to do.
}

Although the above code can display the form, it must be sharp-sighted to see the form because show shows the form in modeless mode. This means that after show displays the new form to the screen, control is immediately returned to the Main function, which exits the process when it returns, and closes the form that was just displayed. To display a form in a modal way, the document recommends using the ShowDialog function:

void __stdcall WinMain(HINSTANCE hInstance,
　　　　　　 HINSTANCE hPrevInstance,
　　　　　long lpCmdLine,
　　　　　int nCmdShow)
{
　Form* form = new Form();
　form->ShowDialog(); // This is not quite what you want to do.
}

Although the code can actually display an empty form and then return control to the Main function after the user closes it, you usually do not write such code. Instead, you will designate a form as the primary form, so that other parts of the application can be accessed as a main form. To do this, you can pass the main form as a parameter to the Run method of the Application object for Windows forms:

#using <mscorlib.dll>
#using <System.dll>
#using <System.Windows.Forms.dll>
using namespace System::Windows::Forms;
void __stdcall WinMain(HINSTANCE hInstance,
　　　　　　 HINSTANCE hPrevInstance,
　　　　　long lpCmdLine,
　　　　　int nCmdShow)
{
　Application::Run(new Form);
}

The static Run method of the application class displays the main form and starts sending Windows messages until the main form is closed. When the main form closes, Run returns, leaving our main function to end the process. To actually see this process, you can use the following command line to compile this small Windows forms application:

C:MSDNMYFIRS~1>CL/CLR MyFirstApp.cpp