.NET Windows Forms 快速参考

需积分: 10 86 浏览量更新于2024-07-31 1 收藏 996KB PDF 举报

"dotNET Windows Forms in a Nutshell" 这本书是关于.NET框架下的Windows Forms开发的一本速查手册，由Ian Griffiths和Matthew Adams撰写。它涵盖了.NET Framework的基础，特别是与Windows桌面应用程序开发相关的方面，包括控件、窗体、菜单、GDI+等多个主题。在.NET和Windows Forms概述中，作者介绍了Windows开发环境的历史变迁以及.NET Framework如何改变了游戏规则。.NET Framework的核心是通用语言运行时（CLR），它为多种编程语言提供了统一的运行平台。.NET编程语言如C#、VB.NET等在此平台上得以运行，并且可以利用.NET组件和类型系统进行高效开发。组件模型允许开发者重用代码和构建模块化应用。书中详细讲解了控件，这是Windows Forms应用的基础元素。Windows Forms和Control类的关系被阐述，以及如何使用标准的控件特性。内置的控件，如按钮、文本框、列表视图等，它们的功能和用法都进行了介绍。在窗体、容器和应用程序部分，作者讨论了.NET应用程序的基本结构，包括Form类的角色，它是用户界面的主要承载者。容器和布局管理是构建复杂界面的关键，书中解释了如何使用不同的布局方式来组织控件。此外，还涉及到了本地化，以便于创建多语言应用。扩展器提供者（Extender Providers）的概念也在此处提及，它们允许控件提供额外的属性或功能。菜单和工具栏章节介绍了如何在Windows Forms中添加和管理菜单项，为用户提供交互式操作选项。最后，关于构建自定义控件的部分，提到了组合控件和自定义控件的创建，这对于开发具有特殊功能的用户界面元素至关重要。这本书的内容深入浅出，对于想要快速掌握.NET Windows Forms开发的程序员来说是一份宝贵的参考资料。通过阅读，读者不仅可以了解Windows Forms的基础，还能学习到如何有效地利用这些知识构建专业级的桌面应用程序。

Chapter 3: Forms, Containers, and Applications

This is the Title of the Book, eMatter Edition

If your application needs to read the command-line parameters, you can modify

Main (or, if you’re coding in Visual Basic, you can add it yourself, rather than have

the compiler add it) so that it takes a parameter of type

string[] or String( ). You

will then be passed an array of strings, one for each argument. You can also

change the return type to

int if you wish to return an exit code. Examples 3-3 and

3-4 illustrate these techniques. The

STAThread custom attribute is a backward-

compatibility feature that will be discussed shortly.

It is also possible to retrieve the command-line arguments using the

Environment class’s GetCommandLineArgs method. You might find

this approach easier because you can call this method anywhere in

your program, not just in Main. It also means you don’t need to

modify the Main method’s signature, and in VB, it means you don’t

need to define a Main method at all.

The Main function turns out to be trivial in the majority of applications because

most interesting initialization takes place inside individual forms. All that happens

Main is an instance of the program’s main user interface (Form1) is created, and

control is then passed to the framework’s

Application class, which manages the

application’s execution for the remainder of its lifetime. The program runs until

the

Application class decides it is time to exit. By default, this is when the main

form is closed.

The Application Class

To do its job, the Windows Forms framework needs to have a high degree of

control over our application. In particular, it must respond correctly to the kind of

input that all Windows applications are required to handle, such as mouse clicks

Example 3-2. An application entry point in VB

<STAThread> Public Shared Sub Main( )

Application.Run(new Form1( ))

End Sub

Example 3-3. C# application entry point with parameters

[STAThread]

static int Main(string[] args)

{

Application.Run(new Form1( ));

}

Example 3-4. VB application entry point with parameters

<STAThread> _

Public Shared Function Main(args As String( )) As Integer

Application.Run(New Form1( ))

End Sub

Application Structure | 57

Forms, Apps,

Containers

This is the Title of the Book, eMatter Edition

and redraw requests. This means the framework needs to be in charge of our appli-

cation’s main thread most of the time; otherwise, it cannot deal with these events.

Although our application’s execution is stage-managed by the framework, we can

still influence its behavior by using the

Application class. For example, we can tell

the framework to shut down our program by calling the

Application.Exit

method. In fact, interacting with the Application class is the first thing most

programs do. They typically start like Example 3-1, calling

Application.Run to

surrender control to Windows Forms. This causes the framework to display the

Form object that it is given, after which it sits and waits for events. From then on,

our code will only be run as a result of some activity, such as a mouse click,

causing the framework to call one of our event handlers.

This event-driven style of execution is an important feature of Windows Forms.

The framework is able to deal with events only because we leave it in charge. Of

course, while one of our event handlers is running (e.g., the code in a

Click

handler is executing), we are temporarily back in charge, which means the frame-

work will be unable to process any other events until our event handler returns.

Most of the time, this is a good thing, because life would become unbearably

complex if we could be asked to start handling a new event before we had finished

dealing with the previous one; reentrant code is notoriously hard to get right, so it

is a good thing that it is not usually required.

The only problem is that if our event handlers take a long time to execute, the

user interface will become unresponsive. Until our code returns control to the

framework, the user will not be able to click on or type into our program, or to

move the windows around. (Strictly speaking the input won’t be lost—such

events are stored in a queue, just as they are with normal Windows programs. But

there will be no response to this input until the handler returns.) We can’t even

give the user a way to abort the operation if it takes too long because the inability

to process user input makes it difficult to support any kind of Cancel button.

While the obvious solution is to avoid writing event handlers that take too long to

execute, this is not always possible. Fortunately, long-running event handlers can

choose to give the framework a chance to deal with any events that may be

queued up and awaiting processing. The

Application class provides a method

called

DoEvents. This handles any pending input and then returns. Of course, any

code that calls this method needs to be careful, because it is inviting reentrant

behavior, so whenever you call this method, you must consider the implications

of another of your event handlers being run before

DoEvents returns. But it does

mean that slow code has a way of making sure the application does not appear to

lock up completely.

The DoEvents method is not the only way of reentering the framework’s event

handling code. Whenever you display a modal dialog (e.g., by using the

MessageBox class, or by displaying a form with the ShowDialog method, as

described later), Windows Forms is once again in charge of your thread and will

process events for you for as long as the window is displayed.

* This is similar to the way that classic Win32 applications must service the message queue.

剩余41页未读，继续阅读

wzhuang1223

粉丝: 0

.NET Windows Forms 快速参考

NET Windows Forms in a Nutshell

Windows Forms编程实战(Windows Forms in Action)

NET Windows Forms in a Nutshell.zip

dotnet windows program

dotnet-一个使用C和WindowsForms实现简单的生日计数器拥有漂亮的UI

Pro .NET 2.0 Windows Forms And Custom Controls In VB 2005_part4of5

Pro .NET 2.0 Windows Forms And Custom Controls In VB 2005_part5of5

Pro .NET 2.0 Windows Forms And Custom Controls In VB 2005_part2of5

Pro .NET 2.0 Windows Forms And Custom Controls In VB 2005_part1of5

Pro .NET 2.0 Windows Forms And Custom Controls In VB 2005_part3of5

最新资源