June 28, 2002

Download the AsynchCalcPi.exe sample.

It all started innocently enough. I found myself needing to calculate the area of a circle for the first time in .NET. This called, of course, for an accurate representation of pi. System.Math.PI is handy, but since it only provides 20 digits of precision, I was worried about the accuracy of my calculation (I really needed 21 digits to be absolutely comfortable). So, like any programmer worth their salt, I forgot about the problem I was actually trying to solve and I wrote myself a program to calculate pi to any number of digits that I felt like. What I came up with is shown in Figure 1.

Figure 1. Digits of Pi application

Progress on Long-Running Operations

While most applications don't need to calculate digits of pi, many kinds of applications need to perform long-running operations, whether it's printing, making a Web service call, or calculating interest earnings on a certain billionaire in the Pacific Northwest. Users are generally content to wait for such things, often moving to something else in the meantime, so long as they can see that progress is being made. That's why even my little application has a progress bar. The algorithm I'm using calculates pi nine digits at a time. As each new set of digits are available, my program keeps the text updated and moves the progress bar to show how we're coming along. For example, Figure 2 shows progress on the way to calculating 1000 digits of pi (if 21 digits are good, than 1000 must be better).

Figure 2. Calculating pi to 1000 digits

The following shows how the user interface (UI) is updated as the digits of pi are calculated:

				
						void ShowProgress(string pi, int totalDigits, int digitsSoFar) {
  _pi.Text = pi;
  _piProgress.Maximum = totalDigits;
  _piProgress.Value = digitsSoFar;
}


				void CalcPi(int digits) {
  StringBuilder pi = new StringBuilder("3", digits + 2);

  // Show progress  ShowProgress(pi.ToString(), digits, 0);

  if( digits > 0 ) {
    pi.Append(".");

    for( int i = 0; i < digits; i += 9 ) {
      int nineDigits = NineDigitsOfPi.StartingAt(i+1);
      int digitCount = Math.Min(digits - i, 9);
      string ds = string.Format("{0:D9}", nineDigits);
      pi.Append(ds.Substring(0, digitCount));

      // Show progress      ShowProgress(pi.ToString(), digits, i + digitCount);
    }
  }
}

Everything was going along fine until, in the middle of actually calculating pi to 1000 digits, I switched away to do something else and then switched back. What I saw is shown in Figure 3.

Figure 3. No paint event for you!

The problem, of course, is that my application is single-threaded, so while the thread is calculating pi, it can't also be drawing the UI. I didn't run into this before because when I set the TextBox.Text and ProgressBar.Value properties, those controls would force their painting to happen immediately as part of setting the property (although I noticed that the progress bar was better at this than the text box). However, once I put the application into the background and then the foreground again, I need to paint the entire client area, and that's a Paint event for the form. Since no other event is going to be processed until we return from the event we're already processing (that is, the Click event on the Calc button), we're out of luck in terms of seeing any further progress. What I really needed to do was free the UI thread for doing UI work and handle the long-running process in the background. For this, I need another thread.

Asynchronous Operations

My current synchronous Click handler looked like this:

void _calcButton_Click(object sender, EventArgs e) {
  CalcPi((int)_digits.Value);
}

Recall that the issue is until CalcPi returns, the thread can't return from our Click handler, which means the form can't handle the Paint event (or any other event, for that matter). One way to handle this is to start another thread, like so:

using System.Threading;
…
int _digitsToCalc = 0;

void CalcPiThreadStart() {
  CalcPi(_digitsToCalc);
}

void _calcButton_Click(object sender, EventArgs e) {
  _digitsToCalc = (int)_digits.Value;
  Thread piThread = new Thread(new ThreadStart(CalcPiThreadStart));              piThread.Start();
}

Now, instead of waiting for CalcPi to finish before returning from the button Click event, I'm creating a new thread and asking it to start. The Thread.Start method will schedule my new thread as ready to start and then return immediately, allowing our UI thread to get back to its own work. Now, if the user wants to interact with the application (put it in the background, move it to the foreground, resize it, or even close it), the UI thread is free to handle all of those events while the worker thread calculates pi at its own pace. Figure 4 shows the two threads doing the work.

Figure 4. Naive multithreading

You may have noticed that I'm not passing any arguments to the worker thread's entry point—CalcPiThreadStart. Instead, I'm tucking the number of digits to calculate into a field, _digitsToCalc, calling the thread entry point, which is calling CalcPi in turn. This is kind of a pain, which is one of the reasons that I prefer delegates for asynchronous work. Delegates support taking arguments, which saves me the hassle of an extra temporary field and an extra function between the functions I want to call.

If you're not familiar with delegates, they're really just objects that call static or instance functions. In C#, they're declared using function declaration syntax. For example, a delegate to call CalcPi looks like this:

delegate void CalcPiDelegate(int digits);

Once I have a delegate, I can create an instance to call the CalcPi function synchronously like so:

void _calcButton_Click(object sender, EventArgs e) {
  CalcPiDelegate  calcPi = new CalcPiDelegate(CalcPi);  calcPi((int)_digits.Value);
}

Of course, I don't want to call CalcPi synchronously; I want to call it asynchronously. Before I do that, however, we need to understand a bit more about how delegates work. My delegate declaration above declares a new class derived from MultiCastDelegate with three functions, Invoke, BeginInvoke, and EndInvoke, as shown here:

class CalcPiDelegate : MulticastDelegate {
  public void Invoke(int digits);  public void BeginInvoke(int digits, AsyncCallback callback,                          object asyncState);  public void EndInvoke(IAsyncResult result);
}

When I created an instance of the CalcPiDelegate earlier and then called it like a function, I was actually calling the synchronous Invoke function, which in turn called my own CalcPi function. BeginInvoke and EndInvoke, however, are the pair of functions that allow you to invoke and harvest the results of a function call asynchronously. So, to have the CalcPi function called on another thread, I need to call BeginInvoke like so:

void _calcButton_Click(object sender, EventArgs e) {
  CalcPiDelegate  calcPi = new CalcPiDelegate(CalcPi);
  calcPi.BeginInvoke((int)_digits.Value, null, null);
}

Notice that we're passing nulls for the last two arguments of BeginInvoke. These are needed if we'd like to harvest the result from the function we're calling at some later date (which is also what EndInvoke is for). Since the CalcPi function updates the UI directly, we don't need anything but nulls for these two arguments. If you'd like the details of delegates, both synchronous and asynchronous, see .NET Delegates: A C# Bedtime Story.

At this point, I should be happy. I've got my application to combine a fully interactive UI that shows progress on a long-running operation. In fact, it wasn't until I realized what I was really doing that I became unhappy.

Multithreaded Safety

As it turned out, I had just gotten lucky (or unlucky, depending on how you characterize such things). Microsoft Windows® XP was providing me with a very robust implementation of the underlying windowing system on which Windows Forms is built. So robust, in fact, that it gracefully handled my violation of the prime directive of Windows programming—Though shalt not operate on a window from other than its creating thread. Unfortunately there's no guarantee that other, less robust implementations of Windows would be equally graceful given my bad manners.

The problem, of course, was of my own making. If you remember Figure 4, I had two threads accessing the same underlying window at the same time. However, because long-running operations are so common in Windows application, each UI class in Windows Forms (that is, every class that ultimately derives from System.Windows.Forms.Control) has a property that you can use from any thread so that you can access the window safely. The name of the property is InvokeRequired, which returns true if the calling thread needs to pass control over to the creating thread before calling a method on that object. A simple Assert in my ShowProgress function would have immediately shown me the error of my ways:

using System.Diagnostics;

void ShowProgress(string pi, int totalDigits, int digitsSoFar) {
  // Make sure we're on the right thread  Debug.Assert(_pi.InvokeRequired == false);
  ...
}

In fact, the .NET documentation is quite clear on this point. It states, "There are four methods on a control that are safe to call from any thread: Invoke, BeginInvoke, EndInvoke, and CreateGraphics. For all other method calls, you should use one of the invoke methods to marshal the call to the control's thread." So, when I set the control properties, I'm clearly violating this rule. And from the names of the first three functions that I'm allowed to call safely (Invoke, BeginInvoke, and EndInvoke), it should be clear that I need to construct another delegate that will be executed in the UI thread. If I were worried about blocking my worker thread, like I was worried about blocking my UI thread, I'd need to use the asynchronous BeginInvoke and EndInvoke. However, since my worker thread exists only to service my UI thread, let's use the simpler, synchronous Invoke method, which is defined like this:

public object Invoke(Delegate method);
public object Invoke(Delegate method, object[] args);

The first overload of Invoke takes an instance of a delegate containing the method we'd like to call in the UI thread, but assumes no arguments. However, the function we want to call to update the UI, ShowProgress, takes three arguments, so we'll need the second overload. We'll also need another delegate for our ShowProgress method so that we can pass the arguments correctly. Here's how to use Invoke to make sure that our calls to ShowProgress, and therefore our use of our windows, shows up on the correct thread (making sure to replace both calls to ShowProgress in CalcPi):

				
						delegate
void ShowProgressDelegate(string pi, int totalDigits, int digitsSoFar);


				void CalcPi(int digits) {
  StringBuilder pi = new StringBuilder("3", digits + 2);

  // Get ready to show progress asynchronously  ShowProgressDelegate showProgress =    new ShowProgressDelegate(ShowProgress);  // Show progress  this.Invoke(showProgress, new object[] { pi.ToString(), digits, 0});

  if( digits > 0 ) {
    pi.Append(".");

    for( int i = 0; i < digits; i += 9 ) {
      ...
      // Show progress      this.Invoke(showProgress,        new object[] { pi.ToString(), digits, i + digitCount});
    }
  }
}

The use of Invoke has finally given me a safe use of multithreading in my Windows Forms application. The UI thread spawns a worker thread to do the long-running operation, and the worker thread passes control back to the UI thread when the UI needs updating. Figure 5 shows our safe multithreading architecture.

Figure 5. Safe multithreading

Simplified Multithreading

The call to Invoke is a bit cumbersome, and because it happens twice in our CalcPi function, we could simplify things and update ShowProgress itself to do the asynchronous call. If ShowProgress is called from the correct thread, it will update the controls, but if it's called from the incorrect thread, it uses Invoke to call itself back on the correct thread. This lets us go back to the previous, simpler CalcPi:

void ShowProgress(string pi, int totalDigits, int digitsSoFar) {
  // Make sure we're on the right thread  if( _pi.InvokeRequired == false ) {
    _pi.Text = pi;
    _piProgress.Maximum = totalDigits;
    _piProgress.Value = digitsSoFar;
  }  else {    // Show progress asynchronously    ShowProgressDelegate showProgress =      new ShowProgressDelegate(ShowProgress);    this.Invoke(showProgress,      new object[] { pi, totalDigits, digitsSoFar});  }
}

void CalcPi(int digits) {
  StringBuilder pi = new StringBuilder("3", digits + 2);

  // Show progress  ShowProgress(pi.ToString(), digits, 0);

  if( digits > 0 ) {
    pi.Append(".");

    for( int i = 0; i < digits; i += 9 ) {
      ...
      // Show progress      ShowProgress(pi.ToString(), digits, i + digitCount);
    }
  }
}

Because Invoke is a synchronous call and we're not consuming the return value (in fact, ShowProgress doesn't have a return value), it's better to use BeginInvoke here so that the worker thread isn't held up, as shown here:

BeginInvoke(showProgress, new object[] { pi, totalDigits, digitsSoFar});

BeginInvoke is always preferred if you don't need the return of a function call because it sends the worker thread to its work immediately and avoids the possibility of deadlock.

Where Are We?

I've used this short example to demonstrate how to perform long-running operations while still showing progress and keeping the UI responsive to user interaction. To accomplish this, I used one asynch delegate to spawn a worker thread and the Invoke method on the main form, along with another delegate to be executed back in the UI thread.

One thing I was very careful never to do was to share access to a single point of data between the UI thread and the worker thread. Instead, I passed a copy of the data needed to do the work to the worker thread (the number of digits), and a copy of the data needed to update the UI (the digits calculated so far and the progress). In the final solution, I never passed references to objects that I was sharing between the two threads, such as a reference to the current StringBuilder (which would have saved me a string copy for every time I went back to the UI thread). If I had passed shared references back and forth, I would have had to use .NET synchronization primitives to make sure to that only one thread had access to any one object at a time, which would have been a lot of work. It was already enough work just to get the calls happening between the two threads without bringing synchronization into it.

Of course, if you've got large datasets that you're working with you're not going to want to copy data around. However, when possible, I recommend the combination of asynchronous delegates and message passing between the worker thread and the UI thread for implementing long-running tasks in your Windows Forms applications.

Acknowledgments

I'd like to thank Simon Robinson for his post on the DevelopMentor .NET mailing list that inspired this article, Ian Griffiths for his initial work in this area, Chris Andersen for his message-passing ideas, and last but certainly not least, Mike Woodring for the fabulous multithreading pictures that I lifted shamelessly for this article.

References

• This article's source code
• .NET Delegates: A C# Bedtime Story
• Win32 Multithreaded Programming by Mike Woodring and Aaron Cohen

Chris Sells is an independent consultant, specializing in distributed applications in .NET and COM, as well as an instructor for DevelopMentor. He's written several books, including ATL Internals, which is in the process of being updated for ATL7. He's also working on Essential Windows Forms for Addison-Wesley and Mastering Visual Studio .NET for O'Reilly. In his free time, Chris hosts the Web Services DevCon and directs the Genghis source-available project. More information about Chris, and his various projects, is available at http://www.sellsbrothers.com.

from: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnforms/html/winforms06112002.asp

为什么选择多线程？

多线程程序要比单线程程序更难于编写，并且不加选择地使用线程也是导致难以找到细小错误的重要原因。这就自然会引出两个问题：为什么不坚持编写单线程代码？如果必须使用多线程，如何才能避免缺陷呢？本文的大部分篇幅都是在回答第二个问题，但首先我要来解释一下为什么确实需要多线程。

多线程处理可以使您能够通过确保程序“永不睡眠”从而保持 UI 的快速响应。大部分程序都有不响应用户的时候：它们正忙于为您执行某些操作以便响应进一步的请求。也许最广为人知的例子就是出现在“打开文件”对话框顶部的组合框。如果在展开该组合框时，CD-ROM驱动器里恰好有一张光盘，则计算机通常会在显示列表之前先读取光盘。这可能需要几秒钟的时间，在此期间，程序既不响应任何输入，也不允许取消该操作，尤其是在确实并不打算使用光驱的时候，这种情况会让人无法忍受。

执行这种操作期间 UI 冻结的原因在于，UI 是个单线程程序，单线程不可能在等待 CD-ROM驱动器读取操作的同时处理用户输入，如图 1 所示。“打开文件”对话框会调用某些阻塞 (blocking) API 来确定 CD-ROM 的标题。阻塞 API 在未完成自己的工作之前不会返回，因此这期间它会阻止线程做其他事情。

在多线程下，像这样耗时较长的任务就可以在其自己的线程中运行，这些线程通常称为辅助线程。因为只有辅助线程受到阻止，所以阻塞操作不再导致用户界面冻结，如图 2 所示。应用程序的主线程可以继续处理用户的鼠标和键盘输入的同时，受阻的另一个线程将等待 CD-ROM 读取，或执行辅助线程可能做的任何操作。

图 2 多线程

其基本原则是，负责响应用户输入和保持用户界面为最新的线程（通常称为 UI 线程）不应该用于执行任何耗时较长的操作。惯常做法是，任何耗时超过 30ms 的操作都要考虑从 UI 线程中移除。这似乎有些夸张，因为 30ms 对于大多数人而言只不过是他们可以感觉到的最短的瞬间停顿，实际上该停顿略短于电影屏幕中显示的连续帧之间的间隔。

如果鼠标单击和相应的 UI 提示（例如，重新绘制按钮）之间的延迟超过 30ms，那么操作与显示之间就会稍显不连贯，并因此产生如同影片断帧那样令人心烦的感觉。为了达到完全高质量的响应效果，上限必须是 30ms。另一方面，如果您确实不介意感觉稍显不连贯，但也不想因为停顿过长而激怒用户，则可按照通常用户所能容忍的限度将该间隔设为 100ms。

这意味着如果想让用户界面保持响应迅速，则任何阻塞操作都应该在辅助线程中执行 — 不管是机械等待某事发生（例如，等待 CD-ROM 启动或者硬盘定位数据），还是等待来自网络的响应。

返回页首

异步委托调用

在辅助线程中运行代码的最简单方式是使用异步委托调用（所有委托都提供该功能）。委托通常是以同步方式进行调用，即，在调用委托时，只有包装方法返回后该调用才会返回。要以异步方式调用委托，请调用 BeginInvoke 方法，这样会对该方法排队以在系统线程池的线程中运行。调用线程会立即返回，而不用等待该方法完成。这比较适合于 UI 程序，因为可以用它来启动耗时较长的作业，而不会使用户界面反应变慢。

例如，在以下代码中，System.Windows.Forms.MethodInvoker 类型是一个系统定义的委托，用于调用不带参数的方法。

private void StartSomeWorkFromUIThread () {
    // The work we want to do is too slow for the UI
    // thread, so let's farm it out to a worker thread.

    MethodInvoker mi = new MethodInvoker(
        RunsOnWorkerThread);
    mi.BeginInvoke(null, null); // This will not block.
}

// The slow work is done here, on a thread
// from the system thread pool.
private void RunsOnWorkerThread() {
    DoSomethingSlow();
}

如果想要传递参数，可以选择合适的系统定义的委托类型，或者自己来定义委托。MethodInvoker 委托并没有什么神奇之处。和其他委托一样，调用 BeginInvoke 会使该方法在系统线程池的线程中运行，而不会阻塞 UI 线程以便其可执行其他操作。对于以上情况，该方法不返回数据，所以启动它后就不用再去管它。如果您需要该方法返回的结果，则 BeginInvoke 的返回值很重要，并且您可能不传递空参数。然而，对于大多数 UI 应用程序而言，这种“启动后就不管”的风格是最有效的，稍后会对原因进行简要讨论。您应该注意到，BeginInvoke 将返回一个 IAsyncResult。这可以和委托的 EndInvoke 方法一起使用，以在该方法调用完毕后检索调用结果。

还有其他一些可用于在另外的线程上运行方法的技术，例如，直接使用线程池 API 或者创建自己的线程。然而，对于大多数用户界面应用程序而言，有异步委托调用就足够了。采用这种技术不仅编码容易，而且还可以避免创建并非必需的线程，因为可以利用线程池中的共享线程来提高应用程序的整体性能。

返回页首

线程和控件

Windows 窗体体系结构对线程使用制定了严格的规则。如果只是编写单线程应用程序，则没必要知道这些规则，这是因为单线程的代码不可能违反这些规则。然而，一旦采用多线程，就需要理解 Windows 窗体中最重要的一条线程规则：除了极少数的例外情况，否则都不要在它的创建线程以外的线程中使用控件的任何成员。

本规则的例外情况有文档说明，但这样的情况非常少。这适用于其类派生自 System.Windows.Forms.Control 的任何对象，其中几乎包括 UI 中的所有元素。所有的 UI 元素（包括表单本身）都是从 Control 类派生的对象。此外，这条规则的结果是一个被包含的控件（如，包含在一个表单中的按钮）必须与包含它控件位处于同一个线程中。也就是说，一个窗口中的所有控件属于同一个 UI 线程。实际中，大部分 Windows 窗体应用程序最终都只有一个线程，所有 UI 活动都发生在这个线程上。这个线程通常称为 UI 线程。这意味着您不能调用用户界面中任意控件上的任何方法，除非在该方法的文档说明中指出可以调用。该规则的例外情况（总有文档记录）非常少而且它们之间关系也不大。请注意，以下代码是非法的：

// Created on UI thread
private Label lblStatus;
...
// Doesn't run on UI thread
private void RunsOnWorkerThread() {
    DoSomethingSlow();
    lblStatus.Text = "Finished!";    // BAD!!
}

如果您在 .NET Framework 1.0 版本中尝试运行这段代码，也许会侥幸运行成功，或者初看起来是如此。这就是多线程错误中的主要问题，即它们并不会立即显现出来。甚至当出现了一些错误时，在第一次演示程序之前一切看起来也都很正常。但不要搞错 — 我刚才显示的这段代码明显违反了规则，并且可以预见，任何抱希望于“试运行时良好，应该就没有问题”的人在即将到来的调试期是会付出沉重代价的。

要注意，在明确创建线程之前会发生这样的问题。使用委托的异步调用实用程序（调用它的 BeginInvoke 方法）的任何代码都可能出现同样的问题。委托提供了一个非常吸引人的解决方案来处理 UI 应用程序中缓慢、阻塞的操作，因为这些委托能使您轻松地让此种操作运行在 UI 线程外而无需自己创建新线程。但是由于以异步委托调用方式运行的代码在一个来自线程池的线程中运行，所以它不能访问任何 UI 元素。上述限制也适用于线程池中的线程和手动创建的辅助线程。

返回页首

在正确的线程中调用控件

有关控件的限制看起来似乎对多线程编程非常不利。如果在辅助线程中运行的某个缓慢操作不对 UI 产生任何影响，用户如何知道它的进行情况呢？至少，用户如何知道工作何时完成或者是否出现错误？幸运的是，虽然此限制的存在会造成不便，但并非不可逾越。有多种方式可以从辅助线程获取消息，并将该消息传递给 UI 线程。理论上讲，可以使用低级的同步原理和池化技术来生成自己的机制，但幸运的是，因为有一个以 Control 类的 Invoke 方法形式存在的解决方案，所以不需要借助于如此低级的工作方式。

Invoke 方法是 Control 类中少数几个有文档记录的线程规则例外之一：它始终可以对来自任何线程的 Control 进行 Invoke 调用。Invoke 方法本身只是简单地携带委托以及可选的参数列表，并在 UI 线程中为您调用委托，而不考虑 Invoke 调用是由哪个线程发出的。实际上，为控件获取任何方法以在正确的线程上运行非常简单。但应该注意，只有在 UI 线程当前未受到阻塞时，这种机制才有效 — 调用只有在 UI 线程准备处理用户输入时才能通过。从不阻塞 UI 线程还有另一个好理由。Invoke 方法会进行测试以了解调用线程是否就是 UI 线程。如果是，它就直接调用委托。否则，它将安排线程切换，并在 UI 线程上调用委托。无论是哪种情况，委托所包装的方法都会在 UI 线程中运行，并且只有当该方法完成时，Invoke 才会返回。

Control 类也支持异步版本的 Invoke，它会立即返回并安排该方法以便在将来某一时间在 UI 线程上运行。这称为 BeginInvoke，它与异步委托调用很相似，与委托的明显区别在于，该调用以异步方式在线程池的某个线程上运行，然而在此处，它以异步方式在 UI 线程上运行。实际上，Control 的 Invoke、BeginInvoke 和 EndInvoke 方法，以及 InvokeRequired 属性都是 ISynchronizeInvoke 接口的成员。该接口可由任何需要控制其事件传递方式的类实现。

由于 BeginInvoke 不容易造成死锁，所以尽可能多用该方法；而少用 Invoke 方法。因为 Invoke 是同步的，所以它会阻塞辅助线程，直到 UI 线程可用。但是如果 UI 线程正在等待辅助线程执行某操作，情况会怎样呢？应用程序会死锁。BeginInvoke 从不等待 UI 线程，因而可以避免这种情况。

现在，我要回顾一下前面所展示的代码片段的合法版本。首先，必须将一个委托传递给 Control 的 BeginInvoke 方法，以便可以在 UI 线程中运行对线程敏感的代码。这意味着应该将该代码放在它自己的方法中，如图 3 所示。一旦辅助线程完成缓慢的工作后，它就会调用 Label 中的 BeginInvoke，以便在其 UI 线程上运行某段代码。通过这样，它可以更新用户界面。

返回页首

包装 Control.Invoke

虽然图 3中的代码解决了这个问题，但它相当繁琐。如果辅助线程希望在结束时提供更多的反馈信息，而不是简单地给出“Finished!”消息，则 BeginInvoke 过于复杂的使用方法会令人生畏。为了传达其他消息，例如“正在处理”、“一切顺利”等等，需要设法向 UpdateUI 函数传递一个参数。可能还需要添加一个进度栏以提高反馈能力。这么多次调用 BeginInvoke 可能导致辅助线程受该代码支配。这样不仅会造成不便，而且考虑到辅助线程与 UI 的协调性，这样设计也不好。对这些进行分析之后，我们认为包装函数可以解决这两个问题，如图 4 所示。

ShowProgress 方法对将调用引向正确线程的工作进行封装。这意味着辅助线程代码不再担心需要过多关注 UI 细节，而只要定期调用 ShowProgress 即可。请注意，我定义了自己的方法，该方法违背了“必须在 UI 线程上进行调用”这一规则，因为它进而只调用不受该规则约束的其他方法。这种技术会引出一个较为常见的话题：为什么不在控件上编写公共方法呢（这些方法记录为 UI 线程规则的例外）？

刚好 Control 类为这样的方法提供了一个有用的工具。如果我提供一个设计为可从任何线程调用的公共方法，则完全有可能某人会从 UI 线程调用这个方法。在这种情况下，没必要调用 BeginInvoke，因为我已经处于正确的线程中。调用 Invoke 完全是浪费时间和资源，不如直接调用适当的方法。为了避免这种情况，Control 类将公开一个称为 InvokeRequired 的属性。这是“只限 UI 线程”规则的另一个例外。它可从任何线程读取，如果调用线程是 UI 线程，则返回假，其他线程则返回真。这意味着我可以按以下方式修改包装：

public void ShowProgress(string msg, int percentDone) {
    if (InvokeRequired) {
        // As before
        ...
    } else {
        // We're already on the UI thread just
        // call straight through.
        UpdateUI(this, new MyProgressEvents(msg,
            PercentDone));
    }
}

ShowProgress 现在可以记录为可从任何线程调用的公共方法。这并没有消除复杂性 — 执行 BeginInvoke 的代码依然存在，它还占有一席之地。不幸的是，没有简单的方法可以完全摆脱它。

返回页首

锁定

任何并发系统都必须面对这样的事实，即，两个线程可能同时试图使用同一块数据。有时这并不是问题 — 如果多个线程在同一时间试图读取某个对象中的某个字段，则不会有问题。然而，如果有线程想要修改该数据，就会出现问题。如果线程在读取时刚好另一个线程正在写入，则读取线程有可能会看到虚假值。如果两个线程在同一时间、在同一个位置执行写入操作，则在同步写入操作发生之后，所有从该位置读取数据的线程就有可能看到一堆垃圾数据。虽然这种行为只在特定情况下才会发生，读取操作甚至不会与写入操作发生冲突，但是数据可以是两次写入结果的混加，并保持错误结果直到下一次写入值为止。为了避免这种问题，必须采取措施来确保一次只有一个线程可以读取或写入某个对象的状态。

防止这些问题出现所采用的方式是，使用运行时的锁定功能。C# 可以让您利用这些功能、通过锁定关键字来保护代码（Visual Basic 也有类似构造，称为 SyncLock）。规则是，任何想要在多个线程中调用其方法的对象在每次访问其字段时（不管是读取还是写入）都应该使用锁定构造。例如，请参见图 5。

锁定构造的工作方式是：公共语言运行库 (CLR) 中的每个对象都有一个与之相关的锁，任何线程均可获得该锁，但每次只能有一个线程拥有它。如果某个线程试图获取另一个线程已经拥有的锁，那么它必须等待，直到拥有该锁的线程将锁释放为止。C# 锁定构造会获取该对象锁（如果需要，要先等待另一个线程利用它完成操作），并保留到大括号中的代码退出为止。如果执行语句运行到块结尾，该锁就会被释放，并从块中部返回，或者抛出在块中没有捕捉到的异常。

请注意，MoveBy 方法中的逻辑受同样的锁语句保护。当所做的修改比简单的读取或写入更复杂时，整个过程必须由单独的锁语句保护。这也适用于对多个字段进行更新 — 在对象处于一致状态之前，一定不能释放该锁。如果该锁在更新状态的过程中释放，则其他线程也许能够获得它并看到不一致状态。如果您已经拥有一个锁，并调用一个试图获取该锁的方法，则不会导致问题出现，因为单独线程允许多次获得同一个锁。对于需要锁定以保护对字段的低级访问和对字段执行的高级操作的代码，这非常重要。MoveBy 使用 Position 属性，它们同时获得该锁。只有最外面的锁阻塞完成后，该锁才会恰当地释放。

对于需要锁定的代码，必须严格进行锁定。稍有疏漏，便会功亏一篑。如果一个方法在没有获取对象锁的情况下修改状态，则其余的代码在使用它之前即使小心地锁定对象也是徒劳。同样，如果一个线程在没有事先获得锁的情况下试图读取状态，则它可能读取到不正确的值。运行时无法进行检查来确保多线程代码正常运行。

返回页首

死锁

锁是确保多线程代码正常运行的基本条件，即使它们本身也会引入新的风险。在另一个线程上运行代码的最简单方式是，使用异步委托调用（请参见图 6）。

如果曾经调用过 Foo 的 CallBar 方法，则这段代码会慢慢停止运行。CallBar 方法将获得 Foo 对象上的锁，并直到 BarWork 返回后才释放它。然后，BarWork 使用异步委托调用，在某个线程池线程中调用 Foo 对象的 FooWork 方法。接下来，它会在调用委托的 EndInvoke 方法前执行一些其他操作。EndInvoke 将等待辅助线程完成，但辅助线程却被阻塞在 FooWork 中。它也试图获取 Foo 对象的锁，但锁已被 CallBar 方法持有。所以，FooWork 会等待 CallBar 释放锁，但 CallBar 也在等待 BarWork 返回。不幸的是，BarWork 将等待 FooWork 完成，所以 FooWork 必须先完成，它才能开始。结果，没有线程能够进行下去。

这就是一个死锁的例子，其中有两个或更多线程都被阻塞以等待对方进行。这里的情形和标准死锁情况还是有些不同，后者通常包括两个锁。这表明如果有某个因果性（过程调用链）超出线程界限，就会发生死锁，即使只包括一个锁！Control.Invoke 是一种跨线程调用过程的方法，这是个不争的重要事实。BeginInvoke 不会遇到这样的问题，因为它并不会使因果性跨线程。实际上，它会在某个线程池线程中启动一个全新的因果性，以允许原有的那个独立进行。然而，如果保留 BeginInvoke 返回的 IAsyncResult，并用它调用 EndInvoke，则又会出现问题，因为 EndInvoke 实际上已将两个因果性合二为一。避免这种情况的最简单方法是，当持有一个对象锁时，不要等待跨线程调用完成。要确保这一点，应该避免在锁语句中调用 Invoke 或 EndInvoke。其结果是，当持有一个对象锁时，将无需等待其他线程完成某操作。要坚持这个规则，说起来容易做起来难。

在检查代码的 BarWork 时，它是否在锁语句的作用域内并不明显，因为在该方法中并没有锁语句。出现这个问题的唯一原因是 BarWork 调用自 Foo.CallBar 方法的锁语句。这意味着只有确保正在调用的函数并不拥有锁时，调用 Control.Invoke 或 EndIn-voke 才是安全的。对于非私有方法而言，确保这一点并不容易，所以最佳规则是，根本不调用 Control.Invoke 和 EndInvoke。这就是为什么“启动后就不管”的编程风格更可取的原因，也是为什么 Control.BeginInvoke 解决方案通常比 Control.Invoke 解决方案好的原因。

有时候除了破坏规则别无选择，这种情况下就需要仔细严格地分析。但只要可能，在持有锁时就应该避免阻塞，因为如果不这样，死锁就难以消除。

返回页首

使其简单

如何既从多线程获益最大，又不会遇到困扰并发代码的棘手错误呢？如果提高的 UI 响应速度仅仅是使程序时常崩溃，那么很难说是改善了用户体验。大部分在多线程代码中普遍存在的问题都是由要一次运行多个操作的固有复杂性导致的，这是因为大多数人更善于思考连续过程而非并发过程。通常，最好的解决方案是使事情尽可能简单。

UI 代码的性质是：它从外部资源接收事件，如用户输入。它会在事件发生时对其进行处理，但却将大部分时间花在了等待事件的发生。如果可以构造辅助线程和 UI 线程之间的通信，使其适合该模型，则未必会遇到这么多问题，因为不会再有新的东西引入。我是这样使事情简单化的：将辅助线程视为另一个异步事件源。如同 Button 控件传递诸如 Click 和 MouseEnter 这样的事件，可以将辅助线程视为传递事件（如 ProgressUpdate 和 WorkComplete）的某物。只是简单地将这看作一种类比，还是真正将辅助对象封装在一个类中，并按这种方式公开适当的事件，这完全取决于您。后一种选择可能需要更多的代码，但会使用户界面代码看起来更加统一。不管哪种情况，都需要 Control.BeginInvoke 在正确的线程上传递这些事件。

对于辅助线程，最简单的方式是将代码编写为正常顺序的代码块。但如果想要使用刚才介绍的“将辅助线程作为事件源”模型，那又该如何呢？这个模型非常适用，但它对该代码与用户界面的交互提出了限制：这个线程只能向 UI 发送消息，并不能向它提出请求。

例如，让辅助线程中途发起对话以请求完成结果需要的信息将非常困难。如果确实需要这样做，也最好是在辅助线程中发起这样的对话，而不要在主 UI 线程中发起。该约束是有利的，因为它将确保有一个非常简单且适用于两线程间通信的模型 — 在这里简单是成功的关键。这种开发风格的优势在于，在等待另一个线程时，不会出现线程阻塞。这是避免死锁的有效策略。

图 7 显示了使用异步委托调用以在辅助线程中执行可能较慢的操作（读取某个目录的内容），然后将结果显示在 UI 上。它还不至于使用高级事件语法，但是该调用确实是以与处理事件（如单击）非常相似的方式来处理完整的辅助代码。

返回页首

取消

前面示例所带来的问题是，要取消操作只能通过退出整个应用程序实现。虽然在读取某个目录时 UI 仍然保持迅速响应，但由于在当前操作完成之前程序将禁用相关按钮，所以用户无法查看另一个目录。如果试图读取的目录是在一台刚好没有响应的远程机器上，这就很不幸，因为这样的操作需要很长时间才会超时。

要取消一个操作也比较困难，尽管这取决于怎样才算取消。一种可能的理解是“停止等待这个操作完成，并继续另一个操作。”这实际上是抛弃进行中的操作，并忽略最终完成时可能产生的后果。对于当前示例，这是最好的选择，因为当前正在处理的操作（读取目录内容）是通过调用一个阻塞 API 来执行的，取消它没有关系。但即使是如此松散的“假取消”也需要进行大量工作。如果决定启动新的读取操作而不等待原来的操作完成，则无法知道下一个接收到的通知是来自这两个未处理请求中的哪一个。

支持取消在辅助线程中运行的请求的唯一方式是，提供与每个请求相关的某种调用对象。最简单的做法是将它作为一个 Cookie，由辅助线程在每次通知时传递，允许 UI 线程将事件与请求相关联。通过简单的身份比较（参见图 8），UI 代码就可以知道事件是来自当前请求，还是来自早已废弃的请求。

如果简单抛弃就行，那固然很好，不过您可能想要做得更好。如果辅助线程执行的是进行一连串阻塞操作的复杂操作，那么您可能希望辅助线程在最早的时机停止。否则，它可能会继续几分钟的无用操作。在这种情况下，调用对象需要做的就不止是作为一个被动 Cookie。它至少还需要维护一个标记，指明请求是否被取消。UI 可以随时设置这个标记，而辅助线程在执行时将定期测试这个标记，以确定是否需要放弃当前工作。

对于这个方案，还需要做出几个决定：如果 UI 取消了操作，它是否要等待直到辅助线程注意到这次取消？如果不等待，就需要考虑一个争用条件：有可能 UI 线程会取消该操作，但在设置控制标记之前辅助线程已经决定传递通知了。因为 UI 线程决定不等待，直到辅助线程处理取消，所以 UI 线程有可能会继续从辅助线程接收通知。如果辅助线程使用 BeginInvoke 异步传递通知，则 UI 甚至有可能收到多个通知。UI 线程也可以始终按与“废弃”做法相同的方式处理通知 — 检查调用对象的标识并忽略它不再关心的操作通知。或者，在调用对象中进行锁定并决不从辅助线程调用 BeginInvoke 以解决问题。但由于让 UI 线程在处理一个事件之前简单地对其进行检查以确定是否有用也比较简单，所以使用该方法碰到的问题可能会更少。

请查看“代码下载”（本文顶部的链接）中的 AsyncUtils，它是一个有用的基类，可为基于辅助线程的操作提供取消功能。图 9 显示了一个派生类，它实现了支持取消的递归目录搜索。这些类阐明了一些有趣的技术。它们都使用 C# 事件语法来提供通知。该基类将公开一些在操作成功完成、取消和抛出异常时出现的事件。派生类对此进行了扩充，它们将公开通知客户端搜索匹配、进度以及显示当前正在搜索哪个目录的事件。这些事件始终在 UI 线程中传递。实际上，这些类并未限制为 Control 类 — 它们可以将事件传递给实现 ISynchronizeInvoke 接口的任何类。图 10 是一个示例 Windows 窗体应用程序，它为 Search 类提供一个用户界面。它允许取消搜索并显示进度和结果。

返回页首

程序关闭

某些情况下，可以采用“启动后就不管”的异步操作，而不需要其他复杂要求来使操作可取消。然而，即使用户界面不要求取消，有可能还是需要实现这项功能以使程序可以彻底关闭。

当应用程序退出时，如果由线程池创建的辅助线程还在运行，则这些线程会被终止。终止是简单粗暴的操作，因为关闭甚至会绕开任何还起作用的 Finally 块。如果异步操作执行的某些工作不应该以这种方式被打断，则必须确保在关闭之前这样的操作已经完成。此类操作可能包括对文件执行的写入操作，但由于突然中断后，文件可能被破坏。

一种解决办法是创建自己的线程，而不用来自辅助线程池的线程，这样就自然会避开使用异步委托调用。这样，即使主线程关闭，应用程序也会等到您的线程退出后才终止。System.Threading.Thread 类有一个 IsBackground 属性可以控制这种行为。它默认为 false，这种情况下，CLR 会等到所有非背景线程都退出后才正常终止应用程序。然而，这会带来另一个问题，因为应用程序挂起时间可能会比您预期的长。窗口都关闭了，但进程仍在运行。这也许不是个问题。如果应用程序只是因为要进行一些清理工作才比正常情况挂起更长时间，那没问题。另一方面，如果应用程序在用户界面关闭后还挂起几分钟甚至几小时，那就不可接受了。例如，如果它仍然保持某些文件打开，则可能妨碍用户稍后重启该应用程序。

最佳方法是，如果可能，通常应该编写自己的异步操作以便可以将其迅速取消，并在关闭应用程序之前等待所有未完成的操作完成。这意味着您可以继续使用异步委托，同时又能确保关闭操作彻底且及时。

返回页首

错误处理

在辅助线程中出现的错误一般可以通过触发 UI 线程中的事件来处理，这样错误处理方式就和完成及进程更新方式完全一样。因为很难在辅助线程上进行错误恢复，所以最简单的策略就是让所有错误都为致命错误。错误恢复的最佳策略是使操作完全失败，并在 UI 线程上执行重试逻辑。如果需要用户干涉来修复造成错误的问题，简单的做法是给出恰当的提示。

AsyncUtils 类处理错误以及取消。如果操作抛出异常，该基类就会捕捉到，并通过 Failed 事件将异常传递给 UI。

返回页首

小结

谨慎地使用多线程代码可以使 UI 在执行耗时较长的任务时不会停止响应，从而显著提高应用程序的反应速度。异步委托调用是将执行速度缓慢的代码从 UI 线程迁移出来，从而避免此类间歇性无响应的最简单方式。

Windows Forms Control 体系结构基本上是单线程，但它提供了实用程序以将来自辅助线程的调用封送返回至 UI 线程。处理来自辅助线程的通知（不管是成功、失败还是正在进行的指示）的最简单策略是，以对待来自常规控件的事件（如鼠标单击或键盘输入）的方式对待它们。这样可以避免在 UI 代码中引入新的问题，同时通信的单向性也不容易导致出现死锁。

有时需要让 UI 向一个正在处理的操作发送消息。其中最常见的是取消一个操作。通过建立一个表示正在进行的调用的对象并维护由辅助线程定期检查的取消标记可实现这一目的。如果用户界面线程需要等待取消被认可（因为用户需要知道工作已确实终止，或者要求彻底退出程序），实现起来会有些复杂，但所提供的示例代码中包含了一个将所有复杂性封装在内的基类。派生类只需要执行一些必要的工作、周期性测试取消，以及要是因为取消请求而停止工作，就将结果通知基类。

from: http://dotnet.csdn.net/n/20060726/92986.html

TestCleanupAttribute
    
    创建一个测试工程。
    打开UnitTest1.cs  它已经为我们生成了一个测试的Sample框架了.

[TestClass]
     public   class  UnitTest1
     {
         public  UnitTest1()
       {
             //
             //  TODO: Add constructor logic here
             //
        }

         /**/ ///   <summary>
         ///  Initialize() is called once during test execution before
         ///  test methods in this test class are executed.
         ///   </summary>
        [TestInitialize()]
         public   void  Initialize()
       {
             //   TODO: Add test initialization code
        }

         /**/ ///   <summary>
         ///  Cleanup() is called once during test execution after
         ///  test methods in this class have executed unless the
         ///  corresponding Initialize() call threw an exception.
         ///   </summary>
        [TestCleanup()]
         public   void  Cleanup()
       {
             //   TODO: Add test cleanup code
        }

        [TestMethod]
         public   void  TestMethod1()
       {
            Assert.IsTrue( true , " this is work " );
        }
    }

    熟悉NUnit的一眼就会明白那些Attribute是干嘛用的了。在里面写了一句简单的断言语句。这样就是一个简单的测试实例了。
    接下来运行这个测试实例。找到Test菜单项,选择"Manage and Execute Tests。在这管理器里面可以选择在项目中已经存在的测试实例。并选择是否运行测试。

 
    单击"By Test List"右边那上工具栏按钮。就开始执行测试了。查看测试结果
双击可以看到详细信息。
    刚才说到的还可以断点调试。很简单，只需要在测试实例设置断点，然后点击刚才的运行按扭的下拉框，可以看到有“Debug Checked tests”。这样就可以调试了。很方便！

    就这么简单！

from: http://www.cnblogs.com/hjf1223/archive/2005/09/22/241757.aspx

　　缺省状态下，一个文件只允许一个人签出，管理员可以通过修改配置，允许多人同时签出。此时，VSS将跟踪所有签出该文件的用户。每当用户签入时，VSS都将和当前存于数据库内的最新版本进行比较，若用户修改的是同一文件的不同处，VSS将进行简单的合并（Merge），否则提示用户，并且不允许签入。用户可以通过VSS提供的Visual Merge工具，比较存放于VSS数据库中的文件和本地文件的异同，手工修改本地文件，直到认为已经可以签入时，方才执行最终签入操作。（参见合并）

2、 合并(Merge)*

　　在VSS中，合并可能发生在3种场合下：使用Multiple Checkout的工作方式；合并原先已经Branch了的文件；获取（Get）文件。

Multiple Checkout：若多个用户同时签出一个文件，第一个用户只要简单的签入就可以了。后续用户也可以签入，但他们的更改将需要和其他所有用户的更改合并，VSS将得到完整的更改内容（参见多人同时签出一个文件）。
Branch：当被Branch的文件合并到其中一个分支时，VSS将会把在另一个分支上所做的改动合并到该分支上（参见对文件和工程的Branch/Share操作）。
Merge on Get：在Multiple Checkout工作方式下，当使用Get Latest Version操作时可能引发合并操作，此时保存在VSS数据库中的内容将合并到本地文件。但如果某个文件是排他性签出的，则不会引发合并操作（参见排他性签出）。

　　在完成一个合并之后，VSS遵循如下规则：

如果仍有冲突，VSS维持文件的签出状态，为了使文件能顺利签入，你必须排除这些冲突。
如果你使用Merge Branches命令，将一个文件合并到一个工程中，而该工程中的对应文件已被签出，该文件将继续保持签出状态（参见对文件和工程的Branch/Share操作）。
在任何其他时候，VSS将会提示你，或者在合并后自动签入，或者保持文件的签出状态以使你在更新VSS数据库中内容之前再核查一边。

　　缺省情况下，当发生冲突时，VSS将启用其Visual Merge工具。

在默认情况下（VSS 6.0）

VSS使用过程中要遵循的是lock-modify-unlock流程而不是 copy-modify-merge流程（比如CVS），即开发人员首先将自己要修改源代码和文档从VSS服务器主备份文件上checkout到本地同时锁定服务器上的源代码和文档（multi - checkout情况除外），修改完成后checkout到服务器上同时解除服务器上文件的锁定。服务器集中控制所有的源程序和文档。

基本的思路是：主GUI上有一个DataGrid，然后新开一个线程进行导入。线程导入数据后，把收集到的错误数据一次性返给主线程，然后显示在原来这个DataGrid中，提供给用户更改并再次导入。

发起一个线程很容易，这里就不讲了，直接进入主题，如果更新主界面上的DataGrid。由于在 .Net中由线程A创建的 控件是不允许其他线程直接修改的。因此，其他线程需要委托线程A，把需要更新的数据给线程A，由他自己去更新。

看如何实现的：

  private delegate void ReBindDataGrid_Delegate(DataTable dt);

  private void ReBindDataGrid(DataTable dt)
  {
   this.dgList.DataSource = dt.DefaultView;
   this.dgList.Refresh();
  }

  private void import_ThreadCompleted(object sender, ThreadCompletedArgs e)
  {

   this.lblIntro.Text += "\n执行完成！";

   if(e.ErrorRows != null)
   {
    ReBindDataGrid_Delegate dt = new ReBindDataGrid_Delegate(ReBindDataGrid);
    this.Invoke(dt,new object[]{e.ErrorRows.Copy()});
   }
   else
   {
    this.pBar.Value = 0;
    this.rtxtInfo.Text += "..Over!";
  }
   this.dgList.Enabled = true;
}

关键在于在主线程声明一个委托：private delegate void ReBindDataGrid_Delegate(DataTable dt);然后在导入线程的完成事件中，利用这个委托，执行主线程中的方法：ReBindDataGrid，同时把参数传给他。

OK，这样就完成了。

关于兼讲委托，只一句话，委托就是在二个不能直接相互操作的对象之间，建立一个桥梁。例如二个线程之间。

from: http://www.wintle.cn/article.asp?id=127

XML是微软.Net战略的一个重要组成部分，而且它可谓是XML Web服务的基石，所以掌握.Net框架下的XML技术自然显得非常重要了。本文将指导大家如何运用C#语言完成.Net框架下的XML文档的读写操作。首先，我会向大家介绍.Net框架中与XML相关的命名空间和其中的重要类。其次，我还会给出有关的实例以使读者更进一步的了解XML文档的读写操作的具体方法。

二．XML命名空间和相关类简介：

在深入进行.Net框架下的XML文档的操作之前，我想很有必要向大家介绍.Net框架中与XML技术有关的命名空间和其中一些重要的类。.Net框架为我们提供了以下一些命名空间：System.Xml、System.Xml.Schema、System.Xml.Serialization、System.Xml.Xpath以及 System.Xml.Xsl来包容和XML操作相关的类。

System.Xml命名空间包含了一些最重要的XML类，其中最主要的类是和XML文档的读写操作相关的类。这些类中包括4个与读相关的类以及2个与写相关的类。它们分别是：XmlReader、XmlTextReader、XmlValidatingReader、XmlNodeReader、XmlWriter以及 XmlTextWriter。本文将重点介绍这些类，因为它们是最基本也是最重要的类。

XmlReader类是一个虚基类，它包含了读XML文档的方法和属性。该类中的Read方法是一个基本的读XML文档的方法，它以流形式读取XML文档中的节点（Node）。另外，该类还提供了ReadString、ReadInnerXml、ReadOuterXml和ReadStartElement等更高级的读方法。除了提供读XML文档的方法外，XmlReader类还为程序员提供了MoveToAttribute、MoveToFirstAttribute、MoveToContent、MoveToFirstContent、MoveToElement以及 MoveToNextAttribute等具有导航功能的方法。在本文后面介绍的实例中，我们将运用到这些方法。

XmlTextReader、XmlNodeReader以及XmlValidatingReader等类是从XmlReader类继承过来的子类。根据它们的名称，我们可以知道其作用分别是读取文本内容、读取节点和读取XML模式（Schemas）。

XmlWriter类为程序员提供了许多写XML文档的方法，它是XmlTextWriter类的基类，我在后面的实例中会给出相关的运用方法。

XmlNode类是一个非常重要的类，它代表了XML文档中的某个节点。该节点可以是XML文档的根节点，这样它就代表整个XML文档了。它是许多很有用的类的基类，这些类包括插入节点的类、删除节点的类、替换节点的类以及在XML文档中完成导航功能的类。同时，XmlNode类还为程序员提供了获取双亲节点、子节点、最后一个子节点、节点名称以及节点类型等的属性。它的三个最主要的子类包括：XmlDocument、XmlDataDocument以及XmlDocumentFragment。XmlDocument类代表了一个XML文档，它提供了载入和保存XML文档的方法和属性。这些方法包括了Load、LoadXml和Save等。同时，它还提供了添加特性（Attributes）、说明（Comments）、空间（Spaces）、元素（Elements）和新节点（New Nodes）等XML项的功能。XmlDocumentFragment类代表了一部分XML文档，它能被用来添加到其他的XML文档中。XmlDataDocument类可以让程序员更好地完成和ADO.NET中的数据集对象之间的互操作。

除了上面介绍的System.Xml命名空间中的类外，该命名空间还包括了XmlConvert、XmlLinkedNode以及XmlNodeList等类，不过这些类不是本文介绍的重点，有兴趣的读者不妨去参考相关文档资料。

System.Xml.Schema命名空间中包含了和XML模式相关的类，这些类包括XmlSchema、XmlSchemaAll、XmlSchemaXPath以及XmlSchemaType等类。

System.Xml.Serialization命名空间中包含了和XML文档的序列化和反序列化操作相关的类，XML文档的序列化操作能将XML格式的数据转化为流格式的数据并能在网络中传输，而反序列化则完成相反的操作，即将流格式的数据还原成XML格式的数据。

System.Xml.XPath命名空间包含了XPathDocument、XPathExression、XPathNavigator以及XPathNodeIterator等类，这些类能完成XML文档的导航功能。在XPathDocument类的协助下，XPathNavigator类能完成快速的XML文档导航功能，该类为程序员提供了许多Move方法以完成导航功能。

System.Xml.Xsl命名空间中的类完成了XSLT的转换功能。

三．读XML文档的方法：

在介绍完.Net框架中和XML有关的命名空间和相关类后，我接着向大家介绍和XML相关的一些操作。首先，我向大家介绍的读取XML文档的方法。在下面的实例程序中，我将运用VS.net开发工具附带的"books.xml"文件来作为示例。你可以在你的机器上搜索到该文件（或请参考附录），或者你也可以运用其他的XML文件。

首先，我们用XmlTextReader类的对象来读取该XML文档。方法很简单，就是在创建新对象的构造函数中指明XML文件的位置即可。

XmlTextReader textReader = new XmlTextReader("C:\\books.xml");

一旦新对象创建完毕，你就可以调用其Read方法来读取XML文档了。调用Read方法之后，信息被存储起来，你可以通过读取该对象的Name、BaseURI、Depth、LineNumber等属性来获取这些信息。下面我给出一个完整的实例，该实例通过简单的读取"books.xml"文件，然后将其中的信息显示在控制台中。

using System;
using System.Xml; 

namespace ReadXml
{
    class Class1
    {
        static void Main( string[] args )
        {
            // 创建一个XmlTextReader类的对象并调用Read方法来读取文件
            XmlTextReader textReader  = new XmlTextReader("C:\\books.xml");
            textReader.Read();
            // 节点非空则执行循环体
            while ( textReader.Read() )
            {
                // 读取第一个元素
                textReader.MoveToElement();
                Console.WriteLine("XmlTextReader Properties Test");
                Console.WriteLine("==================="); 

                // 读取该元素的属性并显示在控制台中
                Console.WriteLine("Name:" + textReader.Name);
                Console.WriteLine("Base URI:" + textReader.BaseURI);
                Console.WriteLine("Local Name:" + textReader.LocalName);
                Console.WriteLine("Attribute Count:" + textReader.AttributeCount.ToString());
                Console.WriteLine("Depth:" + textReader.Depth.ToString());
                Console.WriteLine("Line Number:" + textReader.LineNumber.ToString());
                Console.WriteLine("Node Type:" + textReader.NodeType.ToString());
                Console.WriteLine("Attribute Count:" + textReader.Value.ToString());
            }
        }
    }
}
 

17 votes for this article. Popularity: 5.05. Rating: 4.1 out of 5.

UINT CDragDialogDlg::OnNcHitTest(CPoint point)
{
    CRect r;
    GetClientRect(&r);
    ClientToScreen(&r);

    //Chk to see if the mouse is within //the dialog client areaif(r.PtInRect(point))
    {       
        if(m_mousedown)
        {       
            return HTCAPTION;
        }
    }

    return CDialog::OnNcHitTest(point);

}

																void CDragDialogDlg::OnLButtonDown(UINT nFlags, 
                                   CPoint point)
{   
    m_mousedown = true;     

    CDialog::OnLButtonDown(nFlags, point);
}

void CDragDialogDlg::OnLButtonUp(UINT nFlags, 
                                 CPoint point)
{
    m_mousedown = false;

    CDialog::OnLButtonUp(nFlags, point);
}

																void CDragSDIView::OnLButtonDown(UINT nFlags, 
                                 CPoint point)
{
    m_mousedown = true; 
    ClientToScreen(&point);
    m_lastpoint = point;

    CView::OnLButtonDown(nFlags, point);
}

																void CDragSDIView::OnLButtonUp(UINT nFlags, 
                               CPoint point)
{   
    m_mousedown = false;

    CView::OnLButtonUp(nFlags, point);
}

																void CDragSDIView::OnMouseMove(UINT nFlags, 
                               CPoint point)
{   
    CRect r;
    GetClientRect(&r);
    ClientToScreen(&r);
    ClientToScreen(&point);

    if(r.PtInRect(point))
    {       
        if(m_mousedown)
        {   
            AfxGetMainWnd()->GetWindowRect(&r); 

            AfxGetMainWnd()->MoveWindow(
                r.left - (m_lastpoint.x - point.x),
                r.top - (m_lastpoint.y - point.y),
                r.Width(),r.Height());
            m_lastpoint = point;                
        }
    }

    CView::OnMouseMove(nFlags, point);
}

ReleaseCapture(); //This is not compulsory
POINT pt; 
GetCursorPos(&pt);
POINTS pts = {pt.x, pt.y}; 
::SendMessage(m_hWnd,WM_NCLBUTTONDOWN,HTCAPTION,(LPARAM)&pts);

ReleaseCapture(); //This is not compulsory
::SendMessage(m_hWnd,WM_NCLBUTTONDOWN,HTCAPTION,0);

pWnd->SendMesage(WM_NCLBUTTONDOWN,HTCAPTION,0);

UINT CYourDlg::OnNcHitTest(CPoint point)
{
    UINT hit = CDialog::OnNcHitTest(point);
    if ( hit == HTCLIENT ) 
    {
        return HTCAPTION;
    }
    elsereturn hit;
}

UINT CYourView::OnNcHitTest(CPoint point)
{
    UINT hit = CView::OnNcHitTest(point);
    if (hit == HTCLIENT )
        return HTTRANSPARENT;
    else
    {
        return hit;
    }
}

UINT CMainFrame::OnNcHitTest(CPoint point)
{
    UINT hit = CFrameWnd::OnNcHitTest(point);
    if ( hit == HTCLIENT ) 
    {
        return HTCAPTION;
    }
    elsereturn hit;

}

About Nishant Sivakumar

Editor Site Builder

Nish is a real nice guy living in Atlanta, who has been coding since 1990, when he was 13 years old. Originally from sunny Trivandrum in India, he recently moved to Atlanta from Toronto and is a little sad that he won't be able to play in snow anymore. Nish has been a Microsoft Visual C++ MVP since October, 2002 - awfully nice of Microsoft, he thinks. He maintains an MVP tips and tricks web site - www.voidnish.com where you can find a consolidated list of his articles, writings and ideas on VC++, MFC, .NET and C++/CLI. Oh, and you might want to check out his blog on C++/CLI, MFC, .NET and a lot of other stuff - blog.voidnish.com Nish loves reading Science Fiction, P G Wodehouse and Agatha Christie, and also fancies himself to be a decent writer of sorts. He has authored a romantic comedy Summer Love and Some more Cricket as well as a programming book – Extending MFC applications with the .NET Framework. Nish is currently working on a C++/CLI book for Manning Publications titled C++/CLI in Action. You can read more about the book on his blog. Click here to view Nishant Sivakumar's online profile.

示例工程下载

　　在工业生产控制系统中，有许多需要定时完成的操作，如定时显示当前时间，定时刷新屏幕上的进度条，上位 机定时向下位机发送命令和传送数据等。特别是在对控制性能要求较高的实时控制系统和数据采集系统中，就更需要精确定时操作。
　　众所周知，Windows 是基于消息机制的系统，任何事件的执行都是通过发送和接收消息来完成的。 这样就带来了一些问题，如一旦计算机的CPU被某个进程占用，或系统资源紧张时，发送到消息队列 中的消息就暂时被挂起，得不到实时处理。因此，不能简单地通过Windows消息引发一个对定时要求 严格的事件。另外，由于在Windows中已经封装了计算机底层硬件的访问，所以，要想通过直接利用 访问硬件来完成精确定时，也比较困难。所以在实际应用时，应针对具体定时精度的要求，采取相适 应的定时方法。
　　VC中提供了很多关于时间操作的函数，利用它们控制程序能够精确地完成定时和计时操作。本文详细介绍了 VC中基于Windows的精确定时的七种方式，如下图所示：


图一 图像描述

　　方式一：VC中的WM_TIMER消息映射能进行简单的时间控制。首先调用函数SetTimer()设置定时 间隔，如SetTimer(0,200,NULL)即为设置200ms的时间间隔。然后在应用程序中增加定时响应函数 OnTimer()，并在该函数中添加响应的处理语句，用来完成到达定时时间的操作。这种定时方法非常 简单，可以实现一定的定时功能，但其定时功能如同Sleep()函数的延时功能一样，精度非常低，最小 计时精度仅为30ms，CPU占用低，且定时器消息在多任务操作系统中的优先级很低，不能得到及时响 应，往往不能满足实时控制环境下的应用。只可以用来实现诸如位图的动态显示等对定时精度要求不高的情况。如示例工程中的Timer1。
　　方式二：VC中使用sleep()函数实现延时，它的单位是ms，如延时2秒，用sleep(2000)。精度非常 低，最小计时精度仅为30ms，用sleep函数的不利处在于延时期间不能处理其他的消息，如果时间太 长，就好象死机一样，CPU占用率非常高，只能用于要求不高的延时程序中。如示例工程中的Timer2。
　　方式三：利用COleDateTime类和COleDateTimeSpan类结合WINDOWS的消息处理过程来实现秒级延时。如示例工程中的Timer3和Timer3_1。以下是实现2秒的延时代码：

      COleDateTime      start_time = COleDateTime::GetCurrentTime();
      COleDateTimeSpan  end_time= COleDateTime::GetCurrentTime()-start_time;
      while(end_time.GetTotalSeconds()< 2) //实现延时2秒
     { 
              MSG   msg;
              GetMessage(&msg,NULL,0,0);
              TranslateMessage(&msg); 
              DispatchMessage(&msg);
              
             //以上四行是实现在延时或定时期间能处理其他的消息，
　　　　　　 //虽然这样可以降低CPU的占有率，
             //但降低了延时或定时精度，实际应用中可以去掉。
             end_time = COleDateTime::GetCurrentTime()-start_time;
      }//这样在延时的时候我们也能够处理其他的消息。      

       DWORD dwStart = GetTickCount();
       DWORD dwEnd   = dwStart;
       do
       {
          dwEnd = GetTickCount()-dwStart;
       }while(dwEnd <50);

       DWORD dwStart = GetTickCount();
       DWORD dwEnd   = dwStart;
       do
       {
              MSG   msg;
              GetMessage(&msg,NULL,0,0);
              TranslateMessage(&msg); 
              DispatchMessage(&msg);
              dwEnd = GetTickCount()-dwStart;
       }while(dwEnd <50);

       MMRESULT timeSetEvent（ UINT uDelay, 
                               UINT uResolution, 
                               LPTIMECALLBACK lpTimeProc, 
                               WORD dwUser, 
                               UINT fuEvent ）

       uDelay：以毫秒指定事件的周期。
       Uresolution：以毫秒指定延时的精度，数值越小定时器事件分辨率越高。缺省值为1ms。
       LpTimeProc：指向一个回调函数。
       DwUser：存放用户提供的回调数据。
       FuEvent：指定定时器事件类型：
       TIME_ONESHOT：uDelay毫秒后只产生一次事件
       TIME_PERIODIC ：每隔uDelay毫秒周期性地产生事件。      

       BOOL  QueryPerformanceFrequency(LARGE_INTEGER ＊lpFrequency);
       BOOL  QueryPerformanceCounter(LARGE_INTEGER ＊lpCount);

       typedef union _LARGE_INTEGER
       {
           struct
           {
              DWORD LowPart ;// 4字节整型数
              LONG  HighPart;// 4字节整型数
           };
           LONGLONG QuadPart ;// 8字节整型数
           
        }LARGE_INTEGER ;

       LARGE_INTEGER litmp; 
       LONGLONG QPart1,QPart2;
       double dfMinus, dfFreq, dfTim; 
       QueryPerformanceFrequency(&litmp);
       dfFreq = (double)litmp.QuadPart;// 获得计数器的时钟频率
       QueryPerformanceCounter(&litmp);
       QPart1 = litmp.QuadPart;// 获得初始值
       do
       {
          QueryPerformanceCounter(&litmp);
          QPart2 = litmp.QuadPart;//获得中止值
          dfMinus = (double)(QPart2-QPart1);
          dfTim = dfMinus / dfFreq;// 获得对应的时间值，单位为秒
       }while(dfTim<0.001);

       LARGE_INTEGER litmp; 
       LONGLONG QPart1,QPart2;
       double dfMinus, dfFreq, dfTim; 
       QueryPerformanceFrequency(&litmp);
       dfFreq = (double)litmp.QuadPart;// 获得计数器的时钟频率
       QueryPerformanceCounter(&litmp);
       QPart1 = litmp.QuadPart;// 获得初始值
       Sleep(100);
       QueryPerformanceCounter(&litmp);
       QPart2 = litmp.QuadPart;//获得中止值
       dfMinus = (double)(QPart2-QPart1);
       dfTim = dfMinus / dfFreq;// 获得对应的时间值，单位为秒     

       LARGE_INTEGER litmp; 
       LONGLONG QPart1,QPart2;
       double dfMinus, dfFreq, dfTim; 
       QueryPerformanceFrequency(&litmp);
       dfFreq = (double)litmp.QuadPart;// 获得计数器的时钟频率
       QueryPerformanceCounter(&litmp);
       QPart1 = litmp.QuadPart;// 获得初始值
       do
       {
          QueryPerformanceCounter(&litmp);
          QPart2 = litmp.QuadPart;//获得中止值
          dfMinus = (double)(QPart2-QPart1);
          dfTim = dfMinus / dfFreq;// 获得对应的时间值，单位为秒
       }while(dfTim<0.000001);

CAsyncSocket Socket;
UINT Thread(LPVOID)
{
       Socket.Close ();
       return 0;
}
void CTestSDlg::OnOK() 
{
       // TODO: Add extra validation here
       Socket.Create(0);
       AfxBeginThread(Thread,0,0,0,0,0);
}

其中Socket对象在主线程中被调用，在子线程中被关闭。

跟踪分析

这个问题的原因可以通过单步跟踪(F11)的方法来了解。我们在Socket.Create(0)处设断点，跟踪进去会发现下面的函数被调用：

void PASCAL CAsyncSocket::AttachHandle(
          SOCKET hSocket, CAsyncSocket* pSocket, BOOL bDead)
{
    _AFX_SOCK_THREAD_STATE* pState = _afxSockThreadState;
    BOOL bEnable = AfxEnableMemoryTracking(FALSE);
    if (!bDead)
    {
             ASSERT(CAsyncSocket::LookupHandle(hSocket, bDead) == NULL);
             if (pState->m_pmapSocketHandle->IsEmpty())
             {
                  ASSERT(pState->m_pmapDeadSockets->IsEmpty());
                  ASSERT(pState->m_hSocketWindow == NULL);
                  CSocketWnd* pWnd = new CSocketWnd;
                  pWnd->m_hWnd = NULL;
                  if (!pWnd->CreateEx(0, AfxRegisterWndClass(0),
                                   _T("Socket Notification Sink"),
                                 WS_OVERLAPPED, 0, 0, 0, 0, NULL, NULL))
                 {
                       TRACE0("Warning: unable to create socket notify window!\n");
                       AfxThrowResourceException();
                 }
                 ASSERT(pWnd->m_hWnd != NULL);
                 ASSERT(CWnd::FromHandlePermanent(pWnd->m_hWnd) == pWnd);
                 pState->m_hSocketWindow = pWnd->m_hWnd;
            }
            pState->m_pmapSocketHandle->SetAt((void*)hSocket, pSocket);
    }
    else
    {
           int nCount;
           if (pState->m_pmapDeadSockets->Lookup((void*)hSocket, (void*&)nCount))
                     nCount++;
           else
                     nCount = 1;
           pState->m_pmapDeadSockets->SetAt((void*)hSocket, (void*)nCount);
   }
   AfxEnableMemoryTracking(bEnable);
}

在这个函数的开头，首先获得了一个pState的指针指向_afxSockThreadState对象。从名字可以看出，这似乎是一个和线程相关的变量，实际上它是一个宏，定义如下：

#define _afxSockThreadState AfxGetModuleThreadState()

我们没有必要去细究这个指针的定义是如何的，只要知道它是和当前线程密切关联的，其他线程应该也有类似的指针，只是指向不同的结构。

在这个函数中，CAsyncSocket创建了一个窗口，并把如下两个信息加入到pState所管理的结构中：

    pState->m_pmapSocketHandle->SetAt((void*)hSocket, pSocket);
    pState->m_pmapDeadSockets->SetAt((void*)hSocket, (void*)nCount);
    pState->m_hSocketWindow = pWnd->m_hWnd;
    pState->m_pmapSocketHandle->SetAt((void*)hSocket, pSocket);

当调用Close时，我们再次跟踪，就会发现在KillSocket中，下面的函数出现错误:

    void PASCAL CAsyncSocket::KillSocket(SOCKET hSocket, CAsyncSocket* pSocket)
    {
            ASSERT(CAsyncSocket::LookupHandle(hSocket, FALSE) != NULL);

我们在这个ASSERT处设置断点，跟踪进LookupHandle，会发现这个函数定义如下：

CAsyncSocket* PASCAL CAsyncSocket::LookupHandle(SOCKET hSocket, BOOL bDead)
{
     CAsyncSocket* pSocket;
     _AFX_SOCK_THREAD_STATE* pState = _afxSockThreadState;
     if (!bDead)
     {
             pSocket = (CAsyncSocket*)
             pState->m_pmapSocketHandle->GetValueAt((void*)hSocket);
             if (pSocket != NULL)
                  return pSocket;
    }
    else
    {
             pSocket = (CAsyncSocket*)
                  pState->m_pmapDeadSockets->GetValueAt((void*)hSocket);
             if (pSocket != NULL)
                   return pSocket;
    }
    return NULL;
}

显然，这个函数试图从当前线程查询关于这个 socket的信息，可是这个信息放在创建这个socket的线程中，因此这种查询显然会失败，最终返回NULL。

有人会问，既然它是ASSERT出错，是不是Release就没问题了。这只是自欺欺人。ASSERT/VERIFY都是检验一些程序正常运行必须正确的条件。如果ASSERT都失败，在Release中也许不会显现，但是你的程序肯定运行不正确，啥时候出错就不知道了。

如何在多线程之间传递socket

有些特殊情况下，可能需要在不同线程之间传递socket。当然我不建议在使用CAsyncSOcket的时候这么做，因为这增加了出错的风险（尤其当出现拆解包问题时，有人称为粘包，我基本不认同这种称呼）。如果一定要这么做，方法应该是：

1. 当前拥有这个socket的线程调用Detach方法，这样socket句柄和C++对象及当前线程脱离关系
2. 当前线程把这个对象传递给另外一个线程
3. 另外一个线程创建新的CAsyncSocket对象，并调用Attach

上面的例子，我稍微做修改，就不会出错了：

CAsyncSocket Socket;
UINT Thread(LPVOID sock)
{
         Socket.Attach((SOCKET)sock);
         Socket.Close ();
         return 0;
}
void CTestSDlg::OnOK() 
{
         // TODO: Add extra validation here
         Socket.Create(0);
         SOCKET hSocket = Socket.Detach ();
         AfxBeginThread(Thread,(LPVOID)hSocket,0,0,0,0);
}



from: http://blog.vckbase.com/arong/archive/2005/12/03/15578.html

一、Socket API
    首先应该知道，有Socket1.1提供的原始API函数，和Socket2.0提供的一组扩展函数，两套函数。这两套函数有重复，但是2.0提供的函数功能更强大，函数数量也更多。这两套函数可以灵活混用，分别包含在头文件Winsock.h，Winsock2.h，分别需要引入库wsock32.lib、Ws2_32.lib。

1、默认用作同步阻塞方式，那就是当你从不调用WSAIoctl()和ioctlsocket()来改变Socket IO模式，也从不调用WSAAsyncSelect()和WSAEventSelect()来选择需要处理的Socket事件。正是由于函数accept()，WSAAccept()，connect()，WSAConnect()，send()，WSASend()，recv()，WSARecv()等函数被用作阻塞方式，所以可能你需要放在专门的线程里，这样以不影响主程序的运行和主窗口的刷新。
2、如果作为异步用，那么程序主要就是要处理事件。它有两种处理事件的办法：
    第一种，它常关联一个窗口，也就是异步Socket的事件将作为消息发往该窗口，这是由WinSock扩展规范里的一个函数WSAAsyncSelect()来实现和窗口关联。最终你只需要处理窗口消息，来收发数据。
  第二种，用到了扩展规范里另一个关于事件的函数WSAEventSelect()，它是用事件对象的方式来处理Socket事件，也就是，你必须首先用WSACreateEvent()来创建一个事件对象，然后调用WSAEventSelect()来使得Socket的事件和这个事件对象关联。最终你将要在一个线程里用WSAWaitForMultipleEvents()来等待这个事件对象被触发。这个过程也稍显复杂。
二、CAsyncSocket
    看类名就知道，它是一个异步非阻塞Socket封装类，CAsyncSocket::Create()有一个参数指明了你想要处理哪些Socket事件，你关心的事件被指定以后，这个Socket默认就被用作了异步方式。那么CAsyncSocket内部到底是如何将事件交给你的呢？
    CAsyncSocket的Create()函数，除了创建了一个SOCKET以外，还创建了个CSocketWnd窗口对象，并使用WSAAsyncSelect()将这个SOCKET与该窗口对象关联，以让该窗口对象处理来自Socket的事件(消息)，然而CSocketWnd收到Socket事件之后，只是简单地回调CAsyncSocket::OnReceive()，CAsyncSocket::OnSend()，CAsyncSocket::OnAccept()，CAsyncSocket::OnConnect()等虚函数。所以CAsyncSocket的派生类，只需要在这些虚函数里添加发送和接收的代码。
  
  简化后，大致的代码为：
  bool CAsyncSocket::Create( long lEvent ) file://参数lEvent是指定你所关心的Socket事件
  {
   m_hSocket = socket( PF_INET, SOCK_STREAM, 0 ); file://创建Socket本身

   CSocketWnd* pSockWnd = new CSocketWnd; file://创建响应事件的窗口，实际的这个窗口在AfxSockInit()调用时就被创建了。
   pSockWnd->Create(...);

   WSAAsyncSelect( m_hSocket, pSockWnd->m_hWnd, WM_SOCKET_NOTIFY, lEvent ); file://Socket事件和窗口关联
  }
  
  static void PASCAL CAsyncSocket::DoCallBack(WPARAM wParam, LPARAM lParam)
  {
   CAsyncSocket Socket;
   Socket.Attach( (SOCKET)wParam ); file://wParam就是触发这个事件的Socket的句柄
   int nErrorCode = WSAGETSELECTERROR(lParam); file://lParam是错误码与事件码的合成
   switch (WSAGETSELECTEVENT(lParam))
   {
   case FD_READ:
    pSocket->OnReceive(nErrorCode);
    break;
   case FD_WRITE:
    pSocket->OnSend(nErrorCode);
    break;
   case FD_OOB:
    pSocket->OnOutOfBandData(nErrorCode);
    break;
   case FD_ACCEPT:
    pSocket->OnAccept(nErrorCode);
    break;
   case FD_CONNECT:
    pSocket->OnConnect(nErrorCode);
    break;
   case FD_CLOSE:
    pSocket->OnClose(nErrorCode);
    break;
   }
  }

  CSocketWnd类大致为：

  BEGIN_MESSAGE_MAP(CSocketWnd, CWnd)
   ON_MESSAGE(WM_SOCKET_NOTIFY, OnSocketNotify)
  END_MESSAGE_MAP()

  LRESULT CSocketWnd::OnSocketNotify(WPARAM wParam, LPARAM lParam)
  {
   CAsyncSocket::DoCallBack( wParam, lParam ); file://收到Socket事件消息，回调CAsyncSocket的DoCallBack()函数
   return 0L;
  }

  然而，最不容易被初学Socket编程的人理解的，也是本文最要提醒的一点是，客户方在使用CAsyncSocket::Connect()时，往往返回一个WSAEWOULDBLOCK的错误(其它的某些函数调用也如此)，实际上这不应该算作一个错误，它是Socket提醒我们，由于你使用了非阻塞Socket方式，所以(连接)操作需要时间，不能瞬间建立。既然如此，我们可以等待呀，等它连接成功为止，于是许多程序员就在调用Connect()之后，Sleep(0)，然后不停地用WSAGetLastError()或者CAsyncSocket::GetLastError()查看Socket返回的错误，直到返回成功为止。这是一种错误的做法，断言，你不能达到预期目的。事实上，我们可以在Connect()调用之后等待CAsyncSocket::OnConnect()事件被触发，CAsyncSocket::OnConnect()是要表明Socket要么连接成功了，要么连接彻底失败了。至此，我们在CAsyncSocket::OnConnect()被调用之后就知道是否Socket连接成功了，还是失败了。
  类似的，Send()如果返回WSAEWOULDBLOCK错误，我们在OnSend()处等待，Receive()如果返回WSAEWOULDBLOCK错误，我们在OnReceive()处等待，以此类推。
  还有一点，也许是个难点，那就是在客户方调用Connect()连接服务方，那么服务方如何Accept()，以建立连接的问题。简单的做法就是在监听的Socket收到OnAccept()时，用一个新的CAsyncSocket对象去建立连接，例如：

 void CMySocket::OnAccept( int ErrCode )
 {
       CMySocket* pSocket = new CMySocket;
       Accept( *pSocket );
 }
    于是，上面的pSocket和客户方建立了连接，以后的通信就是这个pSocket对象去和客户方进行，而监听的Socket仍然继续在监听，一旦又有一个客户方要连接服务方，则上面的OnAccept()又会被调用一次。当然pSocket是和客户方通信的服务方，它不会触发OnAccept()事件，因为它不是监听Socket。

三、CSocket
   CSocket是MFC在CAsyncSocket基础上派生的一个同步阻塞Socket的封装类。它是如何又把CAsyncSocket变成同步的，而且还能响应同样的Socket事件呢？
  其实很简单，CSocket在Connect()返回WSAEWOULDBLOCK错误时，不是在OnConnect()，OnReceive()这些事件终端函数里去等待。你先必须明白Socket事件是如何到达这些事件函数里的。这些事件处理函数是靠CSocketWnd窗口对象回调的，而窗口对象收到来自Socket的事件，又是靠线程消息队列分发过来的。总之，Socket事件首先是作为一个消息发给CSocketWnd窗口对象，这个消息肯定需要经过线程消息队列的分发，最终CSocketWnd窗口对象收到这些消息就调用相应的回调函数(OnConnect()等)。
   所以，CSocket在调用Connect()之后，如果返回一个WSAEWOULDBLOCK错误时，它马上进入一个消息循环，就是从当前线程的消息队列里取关心的消息，如果取到了WM_PAINT消息，则刷新窗口，如果取到的是Socket发来的消息，则根据Socket是否有操作错误码，调用相应的回调函数(OnConnect()等)。
  大致的简化代码为：

  BOOL CSocket::Connect( ... )
  {
   if( !CAsyncSocket::Connect( ... ) )
   {
    if( WSAGetLastError() == WSAEWOULDBLOCK ) file://由于异步操作需要时间，不能立即完成，所以Socket返回这个错误
    {
     file://进入消息循环，以从线程消息队列里查看FD_CONNECT消息，直到收到FD_CONNECT消息，认为连接成功。
     while( PumpMessages( FD_CONNECT ) );
    }
   }
  }
  BOOL CSocket::PumpMessages( UINT uEvent )
  {
      CWinThread* pThread = AfxGetThread();
      while( bBlocking ) file://bBlocking仅仅是一个标志，看用户是否取消对Connect()的调用
      {
          MSG msg;
          if( PeekMessage( &msg, WM_SOCKET_NOTIFY ) )
          {
             if( msg.message == WM_SOCKET_NOTIFY && WSAGETSELECTEVENT(msg.lParam) == uStopFlag )
             {
                 CAsyncSocket::DoCallBack( msg.wParam, msg.lParam );
                 return TRUE;
             }     
         }
         else
        {
             OnMessagePending(); file://处理消息队列里的其它消息
             pThread->OnIdle(-1);
        }
     }
  }
  BOOL CSocket::OnMessagePending()
  {
      MSG msg;
       if( PeekMessage( &msg, NULL, WM_PAINT, WM_PAINT, PM_REMOVE ) )
       { file://这里仅关心WM_PAINT消息，以处理阻塞期间的主窗口重画
           ::DispatchMessage( &msg );
           return FALSE;
       }
       return FALSE;
  }

   其它的CSocket函数，诸如Send()，Receive()，Accept()都在收到WSAEWOULDBLOCK错误时，进入PumpMessages()消息循环，这样一个原本异步的CAsyncSocket，到了派生类CSocket，就变成同步的了。
  明白之后，我们可以对CSocket应用自如了。比如有些程序员将CSocket的操作放入一个线程，以实现多线程的异步Socket(通常，同步+多线程 相似于 异步 )。

四、CSocketFile
  另外，进行Socket编程，不能不提到CSocketFile类，其实它并不是用来在Socket双方发送文件的，而是将需要序列化的数据，比如一些结构体数据，传给对方，这样，程序的CDocument()的序列化函数就完全可以和CSocketFile联系起来。例如你有一个CMyDocument实现了Serialize()，你可以这样来将你的文档数据传给Socket的另一方：

 CSocketFile file( pSocket );
 CArchive ar( &file, CArchive::store );
 pDocument->Serialize( ar );
 ar.Close();

  同样，接收一方可以只改变上面的代码为CArchive ar( &file, CArchive::load );即可。
   注意到，CSocketFile类虽然从CFile派生，但它屏蔽掉了CFile::Open()等函数，而函数里仅扔出一个例外。那么也就是说，你不能调用CSocketFile的Open函数来打开一个实实在在的文件，否则会导致例外，如果你需要利用CSocketFile来传送文件，你必须提供CSocketFile类的这些函数的实现。
  再一点，CArchive不支持在datagram的Socket连接上序列化数据。

from: http://www.zahui.com/html/1/2196.htm

概要

更多信息

BOOL SetTimeOut(UINT uTimeOut)

BOOL KillTimeOut()

BOOL OnMessagePending()

示例代码

参考
概要
CSocket 操作，如“接收”(Receive)、“发送”(Send) 和“连接”(Connect) 均是阻塞操作，即要等到操作成功执行完毕或套接字上出现错误后，对这些函数的调用才有返回结果。

在某些情况下，操作可能永远不能成功完成，这将导致程序无限循环等待操作完成。一种解决方法是通过编程限制完成操作使用的时间。本文将讨论这种方法。
 回到顶端

更多信息
这种方法是设置定时，让它在操作时间过长时启动。此方法的关键在于处理定时器的方式。虽然操作是“阻塞的”，但仍然可以处理到达的消息。如果通过使用 SetTimer 设置定时器，那么可以查找 WM_TIMER 消息，并在收到该消息时终止操作。该过程中涉及的主要函数有：
Windows API 调用函数：
::SetTimer
MFC 函数：
CSocket::OnMessagePending
CSocket::CancelBlockingCall
为简单起见，可以在 Csocket 衍生类中封装该功能。

警告：在进一步阅读本文之前，请注意在某些 MFC 版本中存在错误，会在试图使用定时器并重叠 OnMessagePending 时引起问题。这一问题将在下面的 Microsoft Knowledge Base 文章中进行讨论：
137632 (http://support.microsoft.com/kb/137632/EN-US/) 错误：定时器激活时未调用 OnMessagePending
本文仅适用于 Visual C++ 的 1.52、1.52b、2.1 和 2.2 版本。如果使用的是这些 Visual C++ 版本之一，则还需要实施所提供的变通解决方法。

本文最后部分显示提供这种超时功能的类的示例代码。以下内容讲述由该类实现的函数。
 回到顶端

BOOL SetTimeOut(UINT uTimeOut)

调用此函数之后仅接着调用 CSocket 函数（如 Receive、Send 和 Accept）。uTimeOut 参数是以毫秒为单位指定的。之后，进行定时器的设置。如果设置定时器失败，那么函数返回 FALSE。有关详细情况，请参阅 SetTimer 函数的 Windows API 文档。
 回到顶端

BOOL KillTimeOut()

在完成阻塞操作后，必须调用此函数。此函数删除用 SetTimeOut 设置的定时器。如果调用 KillTimer 失败，则返回 FALSE。有关详细情况，请参阅 KillTimer 函数的 Windows API 文档。
 回到顶端

BOOL OnMessagePending()

这是一个虚拟回调函数，在等待操作完成时由 CSocket 类进行调用。此函数给您提供处理传入消息的机会。此实施过程检查用 SetTimeOut 调用函数设置的定时器的 WM_TIMER 消息。如果收到消息，则调用 CancelBlockingCall 函数。有关 OnMessagePending 和 CancelBlockingCall 函数详细的信息，请参阅 MFC 文档。请注意：调用 CancelBlockingCall 函数 将导致操作失败，而且 GetLastError 函数返回 WSAEINTR（表示操作中断）。

下面是使用该类的一个例子：
   ...
   CTimeOutSocket sockServer;
   CAcceptedSocket sockAccept;

   sockServer.Create(777);
   sockServer.Listen();

   // Note the following sequence:
   //  SetTimeOut
   // 
   //  KillTimeOut

   if(!sockServer.SetTimeOut(10000))
   {
     ASSERT(FALSE);
     // Error Handling...for some reason, we could not setup
     // the timer.
   }

   if(!sockServer.Accept(sockAccept))
   {
     int nError = GetLastError();
     if(nError==WSAEINTR)
       AfxMessageBox("No Connections Arrived For 10 Seconds");
      else
        ; // Do other error processing.
   }

   if(!sockServer.KillTimeOut())
   {
     ASSERT(FALSE);
     // Error Handling...for some reason the timer could not
     // be destroyed...perhaps a memory overwrite has changed
     // m_nTimerID?
     //
   }
   ...
 回到顶端

示例代码

   //
   // HEADER FILE
   //
   class CTimeOutSocket : public CSocket
   {
   public:
     BOOL SetTimeOut(UINT uTimeOut);
     BOOL KillTimeOut();
   protected:
     virtual BOOL OnMessagePending();
   private:
     int m_nTimerID;
   };
   //
   // END OF FILE
   //

   //
   // IMPLEMENTATION FILE
   //
   BOOL CTimeOutSocket::OnMessagePending()
   {
     MSG msg;
     if(::PeekMessage(&msg, NULL, WM_TIMER, WM_TIMER, PM_NOREMOVE))
     {
       if (msg.wParam == (UINT) m_nTimerID)
       {
         // Remove the message and call CancelBlockingCall.
         ::PeekMessage(&msg, NULL, WM_TIMER, WM_TIMER, PM_REMOVE);
         CancelBlockingCall();
         return FALSE;  // No need for idle time processing.
       };
     };

     return CSocket::OnMessagePending();
   }

   BOOL CTimeOutSocket::SetTimeOut(UINT uTimeOut)
   {
     m_nTimerID = SetTimer(NULL,0,uTimeOut,NULL);
     return m_nTimerID;
   }

   BOOL CTimeOutSocket::KillTimeOut()
   {
     return KillTimer(NULL,m_nTimerID);
   }
CSOCKET的超时设置和UDP发送接收
    使用CSoket多次了，但对于它的block模式的理解并不是很深入。昨天使用csoket的udp多发测试(server接到数据后，需要通过某种方式将数据发送到client,使用tcp方式比较可靠，我一直这样用的，但是比较费时，需要逐一发送)，发现了问题：

  1）create(),sendto(),receivefrom()....

  2）其中，发送方一直定时发送数据无问题；

  3）而接收方，通过一个单独的接收线程实现( 注意：csocket不能跨线程使用！主线程中socket create()后，detach()并将sock作为lpvoid传入接收线程 )。代码如下：

  //处理接收数据
UINT CSockSvr::DealSvrRevData(LPVOID lParam)
{

  ......
 DWORD dwError;
 TCHAR cBuff[1000];
 CString sIP;
 UINT uPort;
 for(;!pDlg->m_bExit;)
 {
  ::memset( cBuff,0,sizeof(cBuff) );

  // 如果没有接到数据，一直等待。。。。
  // 阻塞模式的弊端：：：在退出时候，通过CancelBlockingCall
   int iRst=SockSvr.ReceiveFrom( cBuff,sizeof(cBuff),sIP,uPort,0 );
    if( iRst!=SOCKET_ERROR )
  {
   CString sTemp=cBuff;
   TRACE1( _T("\r\n Rev Data: %s\r\n"),sTemp );
  }
  else
  {
   dwError=GetLastError();
   TRACE1( _T("\r\n Rev Data Error code: %d\r\n"),dwError );
  }
  ::Sleep(200);
 }
 
 return 0;
}

  问题：如果发送方没有数据，SockSvr.ReceiveFrom()会一致处于等待状态，导致整个处理接收线程的停止，如果用户需要退出/结束程序，无法正确释放资源（无法关闭在线程函数重打开的socket--不能跨线程操作socket，无法关闭线程)，造成系统memory leak...

  针对这种问题，微软的解决办法是：http://support.microsoft.com/default.aspx?scid=kb;zh-cn;138692 ，经过测试，在socket进行connect()的时候不好用。后来，结合微软的办法，我通过自定义的定时器，实现了block超时间后自动退出的功能〉

  #if !defined(AFX_TIMEOUTSOCK_H__19897A81_4EAF_4005_91FD_DC3047725139__INCLUDED_)
#define AFX_TIMEOUTSOCK_H__19897A81_4EAF_4005_91FD_DC3047725139__INCLUDED_

#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000
// TimeOutSock.h : header file
//

/*
CSocket 操作，如接收(Receive)、发送(Send) 和连接(Connect) 均是阻塞操作，
 即要等到操作成功执行完毕或套接字上出现错误后，对这些函数的调用才有返回结果。
某些情况下，操作可能永远不能成功完成，这将导致程序无限循环等待操作完成。
 一种解决方法是通过编程限制完成操作使用的时间。本文将讨论这种方法。
*/
/////////////////////////////////////////////////////////////////////////////
// CTimeOutSock command target

class CTimeOutSock : public CSocket
{
// Attributes
public:

// Operations
public:
 CTimeOutSock();
 virtual ~CTimeOutSock();

// Overrides
public:
 // ClassWizard generated virtual function overrides
 //{{AFX_VIRTUAL(CTimeOutSock)
 public:
 virtual BOOL OnMessagePending();
 //}}AFX_VIRTUAL

 // Generated message map functions
 //{{AFX_MSG(CTimeOutSock)
  // NOTE - the ClassWizard will add and remove member functions here.
 //}}AFX_MSG

/*
//定时器设置block超时 不是很好用。。。徐卫话 2006.4.19
CSocket 操作，如接收(Receive)、发送(Send) 和连接(Connect) 均是阻塞操作，
 即要等到操作成功执行完毕或套接字上出现错误后，对这些函数的调用才有返回结果。
某些情况下，操作可能永远不能成功完成，这将导致程序无限循环等待操作完成。
 一种解决方法是通过编程限制完成操作使用的时间。本文将讨论这种方法。
*/
// 自己计算时间的办法 OK
public:
     BOOL SetTimeOut(UINT uTimeOut=1000);
     BOOL KillTimeOut();
private:
  LONGLONG m_llDtStart;
  UINT  m_uTimeOut;
};

/////////////////////////////////////////////////////////////////////////////

//}
// Microsoft Visual C++ will insert additional declarations immediately before the previous line.

#endif // !defined(AFX_TIMEOUTSOCK_H__19897A81_4EAF_4005_91FD_DC3047725139__INCLUDED_)

  // TimeOutSock.cpp : implementation file
//

#include "stdafx.h"
#include "NetBroad.h"
#include "TimeOutSock.h"

#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

/////////////////////////////////////////////////////////////////////////////
// CTimeOutSock

CTimeOutSock::CTimeOutSock()
{

}

CTimeOutSock::~CTimeOutSock()

// Do not edit the following lines, which are needed by ClassWizard.
#if 0
BEGIN_MESSAGE_MAP(CTimeOutSock, CSocket)
 //}AFX_MSG_MAP
END_MESSAGE_MAP()
#endif // 0

/////////////////////////////////////////////////////////////////////////////
// CTimeOutSock member functions

//设置超时
BOOL CTimeOutSock::SetTimeOut(UINT uTimeOut)
{  
 //get start cnt
 LARGE_INTEGER llCnt;
 ::QueryPerformanceCounter(&llCnt);
 m_llDtStart=llCnt.QuadPart;
 m_uTimeOut=uTimeOut;

     return TRUE;
}

//删除超时参数
BOOL CTimeOutSock::KillTimeOut()
{
 m_llDtStart=0;//表明取消计时
 return TRUE;
}

//检查是否超时间
BOOL CTimeOutSock::OnMessagePending()
{
 // TODO: Add your specialized code here and/or call the base class
 /*
 MSG msg;
  if(::PeekMessage(&msg, NULL, WM_TIMER, WM_TIMER, PM_NOREMOVE))
  {
   if (msg.wParam == (UINT) m_nTimerID)
   {
    // Remove the message and call CancelBlockingCall.
    ::PeekMessage(&msg, NULL, WM_TIMER, WM_TIMER, PM_REMOVE);
    CancelBlockingCall();
    return FALSE;  // No need for idle time processing.
   };
  };
 */
 if( m_llDtStart )
 {
  LARGE_INTEGER lldtEnd;
  ::QueryPerformanceCounter(&lldtEnd); 
  LARGE_INTEGER llFrq;
  ::QueryPerformanceFrequency(&llFrq);
  double dbDealy=(double)(lldtEnd.QuadPart-m_llDtStart)*1000/llFrq.QuadPart;
  if( dbDealy>m_uTimeOut )
  {
   CancelBlockingCall();
   return FALSE;  // No need for idle time processing.
  }
 }
 
 return CSocket::OnMessagePending();
}

  经过改进后， 对处理接收线成的函数进行了部分改进：

  SockSvr.SetTimeOut(500);  int iRst=SockSvr.ReceiveFrom( cBuff,sizeofcBuff),sIP,uPort,0 );  SockSvr.KillTimeOut();

 当block超过定时后，socket自动退出block，防止接收线程停止。问题终于解决了！

from: http://www.arm8.com/cv/1/6/197.html

• FD_CONNECT: 连接事件 , 通常 Client 端 socket 调用 socket API 函数 Connect 时所触发，这个事件发生在 Client 端。
• FD_ACCEPT ：正在引入的连接事件，通常 Server 端 socket 正在接收来自 Client 端 socket 连接时触发，这个事件发生在 Server 端。

　　网络传输服务进程 将 socket 事件 保存至 socket 的事件队列中。此外， 网络传输服务进程 还会向 socket window 发送消息 WM_SOCKET_NOTIFY , 通知有 socket 事件 产生，见下文对 socket window 的详细说明。
　　调用 CSocket::Create 函数后，socket 被创建。 socket 创建过程中调用 CAsyncSocket::AttachHandle(SOCKET hSocket, CAsyncSocket* pSocket, BOOL bDead) 。该函数的作用是：

• 将 socket 实例句柄和 socket 指针添加至 当前模块状态 （ 注 1 ）的一个映射表变量 m_pmapSocketHandle 中。
• 在 AttachHandle 过程中，会 new 一个 CSocketWnd 实例 ( 基于 CWnd 派生 ) ，这里将这个实例称之为 socket window ，进一步理解为它是存放所有 sockets 的消息池 （ window 消息），请仔细查看，这里 socket 后多加了一个 s ，表示创建的多个 socket 将共享一个 消息池 。
• 当 Client 端 socket 与 Server 端相互通信时 , 此时 网络传输服务进程 向 socket window 发送消息 WM_SOCKET_NOTIFY ，需要说明的是 CSocketWnd 窗口句柄保存在 当前模块状态 的 m_hSocketWindow 变量中。

2、阻塞模式

　　阻塞模式下 Server 端与 Client 端之间的通信处于同步状态下。在 Server 端直接实例化 CSocket 类，调用 Create 方法创建 socket ，然后调用方法 Listen 开始侦听，最后用一个 while 循环阻塞调用 Accept 函数用于等待来自 Client 端的连接，如果这个 socket 在主线程（主程序）中运行，这将导致主线程的阻塞。因此，需要创建一个新的线程以运行 socket 服务。
调试跟踪至 CSocket::Accept 函数源码：

while(!Accept(...))
{ 
　　　　　// The socket is marked as nonblocking and no connections are present to be accepted. 
	if (GetLastError() == WSAEWOULDBLOCK) 
	　PumpMessage(FD_ACCEPT); 
	else 
	  return FALSE; 
}

PumpMessage(FD_ACCEPT); 

　　PumpMessage 作为一个消息泵使得 socket window 中的消息能够维持在活动状态。实际跟踪进入 PumpMessage 中，发现这个消息泵与 Accept 函数的调用并不相关，它只是使很少的 socket window 消息（典型的是 WM_PAINT 窗口重绘消息）处于活动状态，而绝大部分的 socket window 消息被阻塞，被阻塞的消息中含有 WM_SOCKET_NOTIFY。
　　很显然，如果没有来自 Client 端 socket 的连接请求， CSocket 就会不断调用 Accept 产生循环阻塞，直到有来自 Client 端 socket 的连接请求而解除阻塞。
　　阻塞解除后，表示 Server 端 socket 和 Client 端 socket 已成功连接， Server 端与 Client 端彼此相互调用 Send 和 Receive 方法开始通信。

3、非阻塞模式

　　在非阻塞模式下 利用 socket 事件 的消息机制， Server 端与 Client 端之间的通信处于异步状态下。
　　通常需要从 CSocket 类派生一个新类，派生新类的目的是重载 socket 事件 的消息函数，然后在 socket 事件 的消息函数中添入合适的代码以完成 Client 端与 Server 端之间的通信，与阻塞模式相比，非阻塞模式无需创建一个新线程。
　　这里将讨论当 Server 端 socket 事件 － FD_ACCEPT 被触发后，该事件的处理函数 OnAccept 是如何进一步被触发的。其它事件的处理函数如 OnConnect, OnReceive 等的触发方式与此类似。
在 1 中已提到 Client/Server 端通信时， Server 端 socket 正在接收来自 Client 端 socket 连接请求，这将会触发 FD_ACCEPT 事件，同时 Server 端的 网络传输服务进程 向 Server 端的 socket window (CSocketWnd ）发送事件通知消息 WM_SOCKET_NOTIFY , 通知有 FD_ACCEPT 事件产生 , CsocketWnd 在收到事件通知消息后，调用消息处理函数 OnSocketNotify:

LRESULT CSocketWnd::OnSocketNotify(WPARAM wParam, LPARAM lParam) 
{ 
	CSocket::AuxQueueAdd(WM_SOCKET_NOTIFY, wParam, lParam); 
	CSocket::ProcessAuxQueue(); 
	return 0L ; 
}

CAsyncSocket* pSocket = CAsyncSocket::LookupHandle((SOCKET)wParam, TRUE); 

　　其实也就是由 socket 句柄得到发送事件通知消息的 socket 指针 pSocket：从 m_pmapSocketHandle 中查找（见 1 ）！
　　最后， WSAGETSELECTEVENT(lParam) 会取出事件类型，在一个简单的 switch 语句中判断事件类型并调用事件处理函数。在这里，事件类型是 FD_ACCEPT ，当然就调用 pSocket->OnAccept ！

结束语
　　Server 端 socket 处于阻塞调用模式下，它必须在一个新创建的线程中工作，防止主线程被阻塞。
　　当有多个 Client 端 socket 与 Server 端 socket 连接及通信时， Server 端采用阻塞模式就显得不适合了，应该采用非阻塞模式 , 利用 socket 事件 的消息机制来接受多个 Client 端 socket 的连接请求并进行通信。
　　在非阻塞模式下，利用 CSocketWnd 作为所有 sockets 的消息池，是实现 socket 事件 的消息机制的关键技术。文中存在用词不妥和可能存在的技术问题，请大家原谅，也请批评指正，谢谢！

注：

1. 当前模块状态——用于保存当前线程和模块状态的一个结构，可以通过 AfxGetThreadModule() 获得。AFX_MODULE_THREAD_STATE 在 CSocket 重新定义为 _AFX_SOCK_THREAD_STATE 。
2. socket 类型——在 TCP/IP 协议中， Client/Server 网络程序采用 TCP 协议：即 socket 类型为 SOCK_STREAM ，它是可靠的连接方式。在这里不采用 UDP 协议：即 socket 类型为 SOCK_DGRAM ，它是不可靠的连接方式。

源代码参考：

1. http://www.codeproject.com/internet/SocketFileTransfer.asp 采用 CSocket 类编写的基于 Client/Server 的网络文件传输程序，它是基于阻塞模式的 Client/Server 端网络程序典型示例。
2. http://www.codeguru.com/Cpp/I-N/network/messaging/article.php/c5453 采用 CSocket 类编写的基于 Client/Server 的网络聊天程序，它是基于非阻塞模式的 Client/Server 端网络程序典型示例。

参考资料：

• Microsoft MSDN Library – January 2001
• 《Windows 网络编程》 清华大学出版社

from: http://www.vckbase.com/document/viewdoc/?id=1375

 bmbk.LoadBitmap(IDB_BITMAP1);

 // 得到位图bitmap的大小
 BITMAP stBitmap;
 bmbk.GetObject(sizeof(BITMAP),&stBitmap);
 CSize bmsize(stBitmap.bmWidth,stBitmap.bmHeight);
 dcMen.CreateCompatibleDC(pDC); // 创建兼容的设备描述表
 // 选入新的位图对象并保存旧的位图对象
 CBitmap *pold=dcMen.SelectObject(&bmbk);
 GetClientRect(&rectbk);
 // 取得客户区的大小
 // 从内存向屏幕复制位图对象
 
 pDC->StretchBlt(rectbk.left,rectbk.top,rectbk.Width(),
  rectbk.Height(),&dcMen,0,0,bmsize.cx,bmsize.cy,SRCCOPY);
 dcMen.SelectObject(pold);
 // 恢复旧的位图对象
 dcMen.DeleteDC();
 // 释放内存设备描述表

 return true;
}

1、显示的图形为什么会闪烁？
    我们的绘图过程大多放在OnDraw或者OnPaint函数中，OnDraw在进行屏
幕显示时是由OnPaint进行调用的。当窗口由于任何原因需要重绘时，
总是先用背景色将显示区清除，然后才调用OnPaint，而背景色往往与绘图内容
反差很大，这样在短时间内背景色与显示图形的交替出现，使得显示窗口看起来
在闪。如果将背景刷设置成NULL，这样无论怎样重绘图形都不会闪了。
当然，这样做会使得窗口的显示乱成一团，因为重绘时没有背景色对原来
绘制的图形进行清除，而又叠加上了新的图形。
    有的人会说，闪烁是因为绘图的速度太慢或者显示的图形太复杂造成的，
其实这样说并不对，绘图的显示速度对闪烁的影响不是根本性的。
例如在OnDraw(CDC *pDC)中这样写：
 pDC->MoveTo(0,0);
 pDC->LineTo(100,100);
这个绘图过程应该是非常简单、非常快了吧，但是拉动窗口变化时还是会看见
闪烁。其实从道理上讲，画图的过程越复杂越慢闪烁应该越少，因为绘图用的
时间与用背景清除屏幕所花的时间的比例越大人对闪烁的感觉会越不明显。
比如：清楚屏幕时间为1s绘图时间也是为1s，这样在10s内的连续重画中就要闪
烁5次；如果清楚屏幕时间为1s不变，而绘图时间为9s，这样10s内的连续重画
只会闪烁一次。这个也可以试验，在OnDraw(CDC *pDC)中这样写：
 for(int i=0;i<100000;i++)
 {
  pDC->MoveTo(0,i);
  pDC->LineTo(1000,i);
 }
呵呵，程序有点变态，但是能说明问题。
    说到这里可能又有人要说了，为什么一个简单图形看起来没有复杂图形那么
闪呢？这是因为复杂图形占的面积大，重画时造成的反差比较大，所以感觉上要
闪得厉害一些，但是闪烁频率要低。
    那为什么动画的重画频率高，而看起来却不闪？这里，我就要再次强调了，
闪烁是什么？闪烁就是反差，反差越大，闪烁越厉害。因为动画的连续两个帧之间
的差异很小所以看起来不闪。如果不信，可以在动画的每一帧中间加一张纯白的帧，
不闪才怪呢。

2、如何避免闪烁
    在知道图形显示闪烁的原因之后，对症下药就好办了。首先当然是去掉MFC
提供的背景绘制过程了。实现的方法很多，
  * 可以在窗口形成时给窗口的注册类的背景刷付NULL
  * 也可以在形成以后修改背景
 static CBrush brush(RGB(255,0,0));
 SetClassLong(this->m_hWnd,GCL_HBRBACKGROUND,(LONG)(HBRUSH)brush);
  * 要简单也可以重载OnEraseBkgnd(CDC* pDC)直接返回TRUE
    这样背景没有了，结果图形显示的确不闪了，但是显示也象前面所说的一样，
变得一团乱。怎么办？这就要用到双缓存的方法了。双缓冲就是除了在屏幕上有
图形进行显示以外，在内存中也有图形在绘制。我们可以把要显示的图形先在内存中
绘制好，然后再一次性的将内存中的图形按照一个点一个点地覆盖到屏幕上去（这个
过程非常快，因为是非常规整的内存拷贝）。这样在内存中绘图时，随便用什么反差
大的背景色进行清除都不会闪，因为看不见。当贴到屏幕上时，因为内存中最终的图形
与屏幕显示图形差别很小（如果没有运动，当然就没有差别），这样看起来就不会闪。

3、如何实现双缓冲
    首先给出实现的程序，然后再解释，同样是在OnDraw(CDC *pDC)中：

 CDC MemDC; //首先定义一个显示设备对象
 CBitmap MemBitmap;//定义一个位图对象

 //随后建立与屏幕显示兼容的内存显示设备
 MemDC.CreateCompatibleDC(NULL);
 //这时还不能绘图，因为没有地方画 ^_^
 //下面建立一个与屏幕显示兼容的位图，至于位图的大小嘛，可以用窗口的大小
 MemBitmap.CreateCompatibleBitmap(pDC,nWidth,nHeight);
  
 //将位图选入到内存显示设备中
 //只有选入了位图的内存显示设备才有地方绘图，画到指定的位图上
 CBitmap *pOldBit=MemDC.SelectObject(&MemBitmap);

 //先用背景色将位图清除干净，这里我用的是白色作为背景
 //你也可以用自己应该用的颜色
 MemDC.FillSolidRect(0,0,nWidth,nHeight,RGB(255,255,255));

 //绘图
 MemDC.MoveTo(……);
 MemDC.LineTo(……);
 
 //将内存中的图拷贝到屏幕上进行显示
 pDC->BitBlt(0,0,nWidth,nHeight,&MemDC,0,0,SRCCOPY);

 //绘图完成后的清理
 MemBitmap.DeleteObject();
 MemDC.DeleteDC();

上面的注释应该很详尽了，废话就不多说了。

4、如何提高绘图的效率
    我主要做的是电力系统的网络图形的CAD软件，在一个窗口中往往要显示成千上万个电力元件，而每个元件又是由点、线、圆等基本图形构成。如果真要在一次重绘过程重画这么多元件，可想而知这个过程是非常漫长的。如果加上了图形的浏览功能，鼠标拖动图形滚动时需要进行大量的重绘，速度会慢得让用户将无法忍受。怎么办？只有再研究研究MFC的绘图过程了。
    实际上，在OnDraw(CDC *pDC)中绘制的图并不是所有都显示了的，例如：你
在OnDraw中画了两个矩形，在一次重绘中虽然两个矩形的绘制函数都有执行，但是很有可能只有一个显示了，这是因为MFC本身为了提高重绘的效率设置了裁剪区。裁剪区的作用就是：只有在这个区内的绘图过程才会真正有效，在区外的是无效的，即使在区外执行了绘图函数也是不会显示的。因为多数情况下窗口重绘的产生大多是因为窗口部分被遮挡或者窗口有滚动发生，改变的区域并不是整个图形而只有一小部分，这一部分需要改变的就是pDC中的裁剪区了。因为显示（往内存或者显存都叫显示）比绘图过程的计算要费时得多，有了裁剪区后显示的就只是应该显示的部分，大大提高了显示效率。但是这个裁剪区是MFC设置的，它已经为我们提高了显示效率，在进行复杂图形的绘制时如何进一步提高效率呢？那就只有去掉在裁剪区外的绘图过程了。可以先用pDC->GetClipBox()得到裁剪区，然后在绘图时判断你的图形是否在这个区内，如果在就画，不在就不画。
如果你的绘图过程不复杂，这样做可能对你的绘图效率不会有提高。

from: http://blog.yesky.com/211/arkcq/1549711.shtml

First of all, how do you find out such a thing? It turns out that the good old Task Manager can display GDI resources consumed by any running process. Use the Task Manager's menu item View>Select Columns and click the GDI Objects checkbox. A new column GDI Object will appear in the Processes view. If a number displayed in that column keeps increasing with time, you know there is a leak.

By watching the Dispatcher process, we noticed that its allotment of GDI objects kept increasing every time the Dispatcher was checking email. Now we had to pinpoint exactly where in our code these resources were leaking. The way to do it is to count the GDI object usage before and after a given operation. The easiest (and most reliable) way to do it is to define an object which counts the resources first in its constructor and then in its destructor. If the numbers differ, it displays the difference. Here's the class we designed for this purpose.

class DbgGuiLeak
{
public:
    explicit DbgGuiLeak ()
    {
        _guiResCount = ::GetGuiResources (::GetCurrentProcess (),
                                          GR_GDIOBJECTS);
    }
    ~DbgGuiLeak ()
    {
        int leaks = ::GetGuiResources (::GetCurrentProcess (), 
                                       GR_GDIOBJECTS) - _guiResCount;
        if (leaks != 0)
        {
            std::cout << "Gui Resources Leaked: " << leaks << std::endl;
        }
    }
private:
    unsigned _guiResCount;
};

This kind of encapsulation has many advantages. Since we are using Resource Management religiously, all our resources are encapsulated in smart objects. The resource are automatically freed in those object's destructors. So if you define any smart object within the scope of the lifetime of your DbgGuiLeak, that object's destructor is guaranteed to be called before the destructor of DbgGuiLeak. C++ language guarantees this LIFO (last-in-first-out) ordering of lifetimes of stack objects. In other words, you won't see any spurious leaks resulting from the arbitrary order of resource deallocation. Compare the two examples below.

In the first example, the leak counter will see no leaks (the destructor of gidObj will free its GDI resource before the destructor of leakCounter is called).

{
    DbgGuiLeak leakCounter;
    SmartGdiObject gdiObj;
    // destructor of gdiObj
    // destructor of leakCounter
}

In the second example, a spurious leak will be displayed only because the implicit destructor of gidObj is called after the last explicit line of code is executed.

{ // bad code!
    unsigned gdiCount = ::GetGuiResources (::GetCurrentProcess (), 
                                           GR_GDIOBJECTS);
    SmartGdiObject gdiObj;
    int leaks = ::GetGuiResources (::GetCurrentProcess (),
                                   GR_GDIOBJECTS) - gdiCount;
    std::cout << "GDI Resources Leaked: " << leaks << std::endl;
    // destructor of gdiObj
}

Using a DLL

To get access to Simple MAPI, we have to use mapi32.dll, a dynamic-load library located in the Windows system directory. A DLL is a resource, so it has to be managed (in the RM sense, not the .NET sense). We define a simple class, Dll, to take care of loading and freeing any DLL.

To call a function defined in a DLL, you have to retrieve a function pointer either by ordinal or, as we do it here, by name. You not only have to know the name of the function, but, because you would like to call it, you must know its signature. The name is passed to Dll::GetFunction as a string argument, but the signature (which is a type) must be passed as a template argument. Internally, we cast the typeless pointer returned by the API to a function pointer of the appropriate signature.

class Dll
{
public:
    Dll (std::string const & filename);
    ~Dll ();

    std::string const & GetFilename () const { return _filename; }

    template <class T>
    void GetFunction (std::string const & funcName, T & funPointer)
    {
        funPointer = static_cast<T> (GetFunction (funcName));
    }

private:
    void * GetFunction (std::string const & funcName) const;

    std::string const _filename;
    HINSTANCE _h;
};

The constructor of Dll calls the LoadLibrary API. (Strictly speaking, we don't need to store the name of the DLL, but it might get handy in case we wanted to display meaningful error reports.)

				
						Dll::Dll
				 (std::string const & filename)
    : _filename (filename),
      _h (::LoadLibrary (filename.c_str ()))
      
{
    if (_h == 0)
        throw "Cannot load dynamic link library";
}

According to the rules of Resource Management, the destructor of the Dll object must free the DLL resource --it does it by calling FreeLibrary.

				
						Dll::~Dll
				 ()
{
    if (_h != 0)
    {
        ::FreeLibrary (_h);
    }
}

A (typeless) function pointer is retrieved from the DLL by calling the GetProcAddress API.

void * Dll::GetFunction (std::string const & funcName) const
{
    void * pFunction = ::GetProcAddress (_h, funcName.c_str ());
    if (pFunction == 0)
    {
        throw "Cannot find function in the dynamic link library";
    }
    return pFunction;
}

Incidentally, when calling the template member function Dll::GetFunction you don't have to explicitly specify the template argument. The complier will deduce it from the type of the second argument. You'll see an example soon.

Simple MAPI

namespace SimpleMapi
{
    class Session
    {
    public:
        Session (Dll & mapi);
        ~Session ();
    private:
        Dll        &_mapi;
        LHANDLE    _h;
    private:
        typedef ULONG (FAR PASCAL *Logon) (ULONG ulUIParam,
                                           LPTSTR lpszProfileName,
                                           LPTSTR lpszPassword,
                                           FLAGS flFlags,
                                           ULONG ulReserved,
                                           LPLHANDLE lplhSession);
        typedef ULONG (FAR PASCAL *Logoff) (LHANDLE session,
                                            ULONG ulUIParam,
                                            FLAGS flFlags,
                                            ULONG reserved);
    };
}

Here is the constructor of a Simple MAPI session. Note that we call the GetFunction template method of Dll without specifying the template parameter. That's because we are giving the compiler enough information through the type Logon (see the typedef above) of the logon argument. Once the (correctly typed) function pointer is initialized, we can make a call through it using the regular function-call syntax.

namespace SimpleMapi
{
    Session::Session (Dll & mapi)
        : _mapi (mapi)
    {
        Logon logon; // logon is a pointer to function
        _mapi.GetFunction ("MAPILogon", logon);
        std::cout << "Mapi Logon" << std::endl;
        ULONG rCode = logon (0, // Handle to window for MAPI dialogs
                            0,  // Use default profile
                            0,  // No password
                            0,  // No flags
                            0,  // Reserved -- must be zero
                            &_h); // Session handle
        if (rCode != SUCCESS_SUCCESS)
            throw "Logon failed";
    }
}

The destructor of SimpleMapi::Session calls MAPILogoff function thus closing the session and (hopefully!) freeing all the resources allocated on its behalf.

namespace SimpleMapi
{
    Session::~Session ()
    {
        Logoff logoff;
        _mapi.GetFunction ("MAPILogoff", logoff);
        std::cout << "Mapi Logoff" << std::endl;
        ULONG rCode = logoff (_h, 0, 0, 0);

        if (rCode != SUCCESS_SUCCESS)
            throw "Logoff failed";
    }
}

Testing for Leaks

Here's our simple test. First we create a DbgGuiLeak object which will remember how many GUI resources are in use before the test starts. Then we create the Dll object which loads mapi32.dll into our address space. Finally, we create a SimpleMapi::Session which logs us into the MAPI subsystem.

What happens next is all the destructors are called in the reverse order of creation. So first the destructor of SimpleMapi::Session logs us off and closes the session. Then the destructor of Dll frees the DLL. Finally, the destructor of DbgGuiLeak checks if any GUI resources have been leaked.

void TestMapi ()
{
    DbgGuiLeak leak;
    Dll mapi ("mapi32.dll");
    SimpleMapi::Session session (mapi);
    // Session destructor logs off
    // Dll destructor frees library
    // DbgGuiLeak destructor prints leak info
}

The main function of our program calls TestMapi three times, to get past any transcient effects (not that we think it's ok for the first logon to leak resources--but it wouldn't be such a disaster).

int main ()
{
    try
    {
        TestMapi ();
        TestMapi ();
        TestMapi ();
    }
    catch (char const * msg)
    {
        std::cerr << msg << std::endl;
    }
}

For completeness, these are the files you have to include in the test program for it to compile:

#include <windows.h>
#include <mapi.h>
#include <iostream>

Now you are ready to compile and run the test. Results may vary, depending on what email client is installed on your computer and what security updates you have downloaded from Microsoft. Here are some typical results for a well-updated system with Microsoft Outlook Express.

C:\Test\MapiCons\Release>mapicons
Mapi Logon
Mapi Logoff
Gui Resources Leaked: 16
Mapi Logon
Mapi Logoff
Gui Resources Leaked: 2
Mapi Logon
Mapi Logoff
Gui Resources Leaked: 2

The first logon leaks 16 GDI resources, which is bad, but not terminally so. What is really bad is that every subsequent logon/logoff sequence leaks two additional resources. There is no excuse for this kind of shabby programming.

Microsoft acknowledges having a similar problem with their Exchange Server

from: http://www.relisoft.com/win32/gdileaks.html

Overview

CFileDialog(BOOL bOpenFileDialog,
	   LPCTSTR lpszDefExt = NULL,
	   LPCTSTR lpszFileName = NULL,
	   DWORD dwFlags = OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
	   LPCTSTR lpszFilter = NULL,
	   CWnd* pParentWnd = NULL );

The only member variable that the File Dialog has is called m_ofn. It is an object derived from a Win32 class (or structure) called OPENFILENAME. In fact, the MFC doesn't do miracles than the Win32 would. The MFC only provides some type of "translation" of the Win32 library on this issue.

The OPENFILENAME class is defined as follows:

typedef struct tagOFN { 
  DWORD         lStructSize; 
  HWND          hwndOwner; 
  HINSTANCE     hInstance; 
  LPCTSTR       lpstrFilter; 
  LPTSTR        lpstrCustomFilter; 
  DWORD         nMaxCustFilter; 
  DWORD         nFilterIndex; 
  LPTSTR        lpstrFile; 
  DWORD         nMaxFile; 
  LPTSTR        lpstrFileTitle; 
  DWORD         nMaxFileTitle; 
  LPCTSTR       lpstrInitialDir; 
  LPCTSTR       lpstrTitle; 
  DWORD         Flags; 
  WORD          nFileOffset; 
  WORD          nFileExtension; 
  LPCTSTR       lpstrDefExt; 
  LPARAM        lCustData; 
  LPOFNHOOKPROC lpfnHook; 
  LPCTSTR       lpTemplateName; 
#if (_WIN32_WINNT >= 0x0500)
  void *        pvReserved;
  DWORD         dwReserved;
  DWORD         FlagsEx;
#endif // (_WIN32_WINNT >= 0x0500)
} OPENFILENAME, *LPOPENFILENAME;
File Dialog Operations
In order to use a File Dialog box, the user must open it. This can be done by calling the CFileDialog::DoModal() method. 
When it comes up, the File Dialog displays two buttons regularly available on a normal dialog box. If the file is being opened, the buttons are Open and Cancel. If the user is saving a file, the buttons are Save and Cancel. After using the dialog box, either to open or to save a file, the user can click Open/Save or Cancel. If the user clicks Open or Save, the dialog box is (partly) equipped to validate the operation. For example, if the user clicks Open, the dialog box is configured to make sure that the user selected a file. If the user clicks Save, he or she should have given a name to the file. To dismiss the dialog box without continuing with the intended operation, the user can click Cancel. If the user clicks Cancel, the dialog box throws a CommDlgExtendedError. This error allows you to find out what happens: maybe the user didn't click Cancel, maybe the dialog box was not even created, maybe this, maybe that. This error allows you to diagnose a potential problem and deal with it. If you don't want to go through this, you can just cancel the operation yourself. 
After displaying the File Dialog box, in other to effectively perform an intended operation, the user must provide a name for the file. To find out what name the user provided, you can call the CFileDialog::GetFileName() method. Its syntax is: 
CString GetFileName( ) const;
A file name is indeed made of various sections. In the strict sense, the file name is a long string that starts from its drive all the way to its "normal" name. This is also referred to as its path. To get the path of the being dealt with, you can call the CFileDialog::GetPathName() method. Its syntax is: 
CString GetPathName( ) const;
In the traditional sense, the name of a file ends with 2, 3, or 4 characters known as its extension. For example, the extension of a Microsoft Word file is doc. The extension of a Perl file is pl. After the user has dealt with a file or while dealing with it, to find out the extension of that file, you can call the CFileDialog::GetFileExt() method. Its syntax is: 
CString GetFileExt( ) const;
 Practical Learning: Using the File Dialog Box
If you want to follow with this example, create a New Dialog Based application named FileProc 
Design the dialog box as follows:
  
Control
ID
Caption
Additional Properties
Static Text
Make: 
 
Edit Box
IDC_MAKE
 
 
Static Text
 
Model:
 
Edit Box
IDC_MODEL
 
 
Static Text
 
Year:
 
Edit Box
IDC_YEAR
 
Align Text: Right
Static Text
 
Mileage:
 
Edit Box
IDC_MILEAGE
 
Align Text: Right
Static Text
 
Owner
 
Edit Box
IDC_OWNER
 
 
Button
IDC_SAVE_BTN
&Save
 
Button
IDC_OPEN_BTN
&Open
 
Button
IDCANCEL
Close
 
Using either the ClassWizard or the Add Member Variable Wizard, add the following member variables to the controls:
  
Identifier
Value Variable
IDC_MAKE
CString
m_Make
IDC_MODEL
CString
m_Model
IDC_YEAR
CString
m_Year
IDC_MILEAGE
CString
m_Doors
IDC_OWNER
CString
m_Owner
Generate a BN_CLICKED message for the IDC_SAVE_BTN button and, after accepting the suggested name of the event, implement it as follows:
  
void CFileProc1Dlg::OnSaveBtn() 
{
	// TODO: Add your control notification handler code here
	this->UpdateData();

	CFile f;

	char strFilter[] = { "BCR Files (*.bcr)|*.bcr|All Files (*.*)|*.*||" };

	CFileDialog FileDlg(FALSE, ".bcr", NULL, 0, strFilter);

	if( FileDlg.DoModal() == IDOK )
	{
	f.Open(FileDlg.GetFileName(), CFile::modeCreate | CFile::modeWrite);
		CArchive ar(&f, CArchive::store);

		ar << m_Make << m_Model << m_Year << m_Mileage << m_Owner;
		ar.Close();
	}
	else
		return;

	f.Close();
}
Generate a BN_CLICKED message for the IDC_OPEN_BTN button and, after accepting the suggested name of the event, implement it as follows:
  
void CFileProc1Dlg::OnOpenBtn() 
{
	// TODO: Add your control notification handler code here
	this->UpdateData();

	CFile f;

	char strFilter[] = { "BCR Files (*.bcr)|*.bcr|All Files (*.*)|*.*||" };

	CFileDialog FileDlg(TRUE, ".bcr", NULL, 0, strFilter);

	if( FileDlg.DoModal() == IDOK )
	{
		if( f.Open(FileDlg.GetFileName(), CFile::modeRead) == FALSE )
			return;
		CArchive ar(&f, CArchive::load);

		ar >> m_Make >> m_Model >> m_Year >> m_Mileage >> m_Owner;
		ar.Close();
	}
	else
		return;

	f.Close();
	this->UpdateData(FALSE);
}
Test the application 
Create and save a file
 
Close the dialog box 
Test the application again 
Open the previously created file 

from: http://www.functionx.com/visualc/controls/filedialog.htm

2，MFC中菜单项消息如果利用ClassWizard来对菜单项消息分别在上述四个类中进行响应，则菜单消息传递顺序：View类--Doc类--CMainFrame类--App类。菜单消息一旦在其中一个类中响应则不再在其它类中查找响应函数。
具体：
当点击一个菜单项的时候，最先接受到菜单项消息的是CMainFrame框架类，CMainFrame框架类将会把菜单项消息交给它的子窗口View类，由View类首先进行处理；如果View类检测到没对该菜单项消息做响应，则View类把菜单项消息交由文档类Doc类进行处理；如果Doc类检测到Doc类中也没对该菜单项消息做响应，则Doc类又把该菜单项消息交还给View类，由View类再交还给CMainFrame类处理。如果CMainFrame类查看到CMainFrame类中也没对该消息做响应，则最终交给App类进行处理。

3，消息的分类：标准消息，命令消息，通告消息。
[标准消息]：除WM_COMMAND之外，所有以WM_开头的消息。
[命令消息]：来自菜单、加速键或工具栏按钮的消息。这类消息都以WM_COMMAND呈现。
在MFC中，通过菜单项的标识（ID）来区分不同的命令消息；在SDK中，通过消息的wParam参数识别。
[通告消息]：由控件产生的消息，例如，按钮的单击，列表框的选择等均产生此类消息，为的是向其父窗口（通常是对话框）通知事件的发生。这类消息也是以WM_COMMAND形式呈现。
说明：
1）从CWnd派生的类，都可以接收到[标准消息]。
2）从CCmdTarget派生的类，都可以接收到[命令消息]和[通告消息]。

4，一个菜单拦可以有若干个子菜单，一个子菜单又可以有若干个菜单项等。对菜单栏的子菜单由左至右建立从0开始的索引。对特定子菜单的菜单项由上至下建立了从0开始的索引。访问子菜单和菜单项均可以通过其索引或标识（如果有标识的话）进行。
相关重要函数：
CMenu* GetMenu( ) ;//CWnd::GetMenu得到窗口菜单栏对象指针。
CMenu* GetSubMenu(  ) ;//CMenu::GetSubMenu获得指向弹出菜单对象指针
UINT CheckMenuItem( );//CMenu::CheckMenuItem Adds check marks to or removes check marks from menu items in the pop-up menu.
BOOL SetDefaultItem();//CMenu::SetDefaultItem Sets the default menu item for the specified menu.
BOOL SetMenuItemBitmaps( );//CMenu::SetMenuItemBitmaps 设置位图标题菜单。
UINT EnableMenuItem();//CMenu::EnableMenuItem使菜单项有效，无效，或变灰。
BOOL SetMenu( CMenu* pMenu );//CWnd::SetMenu在当前窗口上设置新菜单或移除菜单。
HMENU Detach( );//CMenu::Detach Detaches a Windows menu from a CMenu object and returns the handle.
说明：
1）在计算子菜单菜单项的索引的时候，分隔栏符也算索引的。
2）int GetSystemMetrics()获取系统信息度量。可以用它来获取菜单标题的尺寸从而设置位图标题菜单中位图的大小。
3）在MFC中MFC为我们提供了一套命令更新机制，所有菜单项的更新都是由这套机制来完成的。所以要想利用CMenu::EnableMenuItem来自己控制菜单使用或不使用变灰等，必须要在CMainFrame的构造函数中将变量m_bAutoMenuEnable设置为FALSE。
4）Create a CMenu object on the stack frame as a local, then call CMenu’s member functions to manipulate the new menu as needed. Next, call CWnd::SetMenu to set the menu to a window, followed immediately by a call to the CMenu object’s Detach member function. The CWnd::SetMenu member function sets the window’s menu to the new menu, causes the window to be redrawn to reflect the menu change, and also passes ownership of the menu to the window. The call to Detach detaches the HMENU from the CMenu object, so that when the local CMenu variable passes out of scope, the CMenu object destructor does not attempt to destroy a menu it no longer owns. The menu itself is automatically destroyed when the window is destroyed.
5）You can use the LoadMenuIndirect member function to create a menu from a template in memory, but a menu created from a resource by a call to LoadMenu is more easily maintained, and the menu resource itself can be created and modified by the menu editor.
6）EXAMPLE：
CMenu menu;//定义为局部对象
menu.LoadMenu(IDR_MAINFRAME);
SetMenu(&menu);
menu.Detach();// 这里menu对象作为一个局部对象。使用Detach()从menu对象中分离窗口菜单句柄，从而当menu对象析构的时候窗口菜单资源不随之销毁。

5，命令更新机制：
菜单项状态的维护是依赖于CN_UPDATE_COMMAND_UI消息，谁捕获CN_UPDATE_COMMAND_UI消息，MFC就在其中创建一个CCmdUI对象。
在后台操作系统发出WM_INITMENUPOPUP消息，然后由MFC的基类如CFrameWnd接管并创建一个CCmdUI对象和第一个菜单项相关联，调用对象成员函数DoUpdate()（注：这个函数在MSDN中没有找到说明）发出CN_UPDATE_COMMAND_UI消息，这条消息带有指向CCmdUI对象的指针。此后同一个CCmdUI对象又设置为与第二个菜单项相关联，这样顺序进行，直到完成所有菜单项。
更新命令UI处理程序仅应用于弹出式菜单项上的项目，不能应用于永久显示的顶级菜单项目。
说明：
1）可以手工或用ClassWizard来给菜单项添加UPDATE_COMMAND_UI消息响应，利用响应函数中传进来的CCmdUI对象指针可完成设置菜单项可使用，不可使用，变灰，设置标记菜单等操作。

6，如果要想让工具栏上的某个图标与菜单项的某个菜单相关联，只需要将图标的ID设置为该菜单项的ID。
工具栏图标的索引记数顺序是：从做至右从0开始，分隔符也算索引号。

7,利用向项目中添加VC的POPMENU控件：Project->Add to Project->Components and Controls..
系统增加的内容：A，一个菜单资源；B，在派生View类中增加了OnContextMenu()函数
说明：
1）CWnd::OnContextMenu Called by the framework when the user has clicked the right mouse button (right clicked) in the window. You can process this message by displaying a context menu using the TrackPopupMenu.
2）BOOL TrackPopupMenu( UINT nFlags, int x, int y, CWnd* pWnd, LPCRECT lpRect = NULL );
//CMenu::TrackPopupMenu Displays a floating pop-up menu at the specified location and tracks the selection of items on the pop-up menu. A floating pop-up menu can appear anywhere on the screen.

8，利用调用TrackPopupMenu函数，手工添加弹出菜单：
1）用资源管理器添加一个菜单资源
2）在鼠标右键消息响应函数中，加载菜单资源，并获得要显示的子菜单指针，并用该指针调用TrackPopupMenu函数便完成任务（但要注意：鼠标响应函数传进来的坐标是客户区坐标，而TrackPopupMenu函数中使用的是屏幕坐标，在调用TrackPopupMenu前要调用ClientToScreen客户区坐标到屏幕坐标的转换）
事例代码：
CMenu menu;
menu.LoadMenu(IDR_MENU1);
CMenu *pPopup=menu.GetSubMenu(0);
ClientToScreen(&point);
pPopup->TrackPopupMenu(TPM_LEFTALIGN | TPM_RIGHTBUTTON, point.x, point.y,this);
说明：
CWnd::ClientToScreen(..);//将一个坐标点或一个矩形区域坐标转换成屏幕坐标。
CMenu::TrackPopupMenu(..);//在指定位置以指定的方式显示弹出菜单。
CWnd::ScreenToClient(..);
//Converts the screen coordinates of a given point or rectangle on the display to client coordinates.

9,当弹出菜单属于框架窗口的时候（可在TrackPopupMenu函数参数中设置），弹出菜单上的消息，在路由的时候，仍然遵循View-DOC-MainFrame-APP的响应顺序。

10，动态菜单编程：
所有的资源对象都有一个数据成员保存了资源的句柄。
CMenu::AppendMenu //Appends a new item to the end of a menu.
CMenu::CreatePopupMenu //Creates an empty pop-up menu and attaches it to a CMenu object.
CMenu::InsertMenu
//Inserts a new menu item at the position specified by nPosition and moves other items down the menu.
CMenu::GetSubMenu //Retrieves a pointer to a pop-up menu.
CWnd::GetMenu //Retrieves a pointer to the menu for this window.
CMenu::DeleteMenu //Deletes an item from the menu.

11，手动给动态菜单项添加响应函数：
在Resource.h中可以添加资源的ID
在头文件中写消息函数原型
在代码文件中添加消息映射和添加消息响应函数
说明：
可以先创建一个临时的菜单项，设置它的ID和动态菜单项的一致，然后对它用向导进行消息响应，然后删除临时菜单。
再在代码文件中把消息映射放到宏外（注意一定要放到宏外面，因为CLASSWIZARD发现菜单删除了，同时要把其宏对里的消息映射也删除掉的）

12，CWnd::DrawMenuBar
//Redraws the menu bar. If a menu bar is changed after Windows has created the window, call this function to draw the changed menu bar

CWnd::GetParent //get a pointer to a child window’s parent window (if any).
CWnd::Invalidate //注意其参数的作用

13，集合类：
CStringArray，CStringArray，CDWordArray，CPtrArray，CStringArray，CUIntArray，CWordArray
其中成员函数：
CArray::GetAt
CArray::Add

14,命令消息是到OnCommand函数的时候完成路由的。
由于CWnd::OnCommand 是个虚函数，可以在框架类中重写OnCommand函数，从而可以截获菜单消息使它不再往下（VIEW类）路由。
例：
BOOL CMainFrame::OnCommand(WPARAM wParam, LPARAM lParam)
{
 // TODO: Add your specialized code here and/or call the base class
 int MenuCmdId=LOWORD(wParam);//取命令ID
 CMenu2View *pView=(CMenu2View*)GetActiveView();//获取当前VIEW类指针
 if(MenuCmdId>=IDM_PHONE1 && MenuCmdId<IDM_PHONE1+pView->m_strArray.GetSize())//消息范围判断
 {
  CClientDC dc(pView);
  dc.TextOut(0,0,pView->m_strArray.GetAt(MenuCmdId-IDM_PHONE1));
  return TRUE;
   //函数返回，避免调用CFrameWnd::OnCommand函数，在CFrameWnd::OnCommand中截获的消息会交由VIEW类处理
 }
 return CFrameWnd::OnCommand(wParam, lParam);
  //调用基类OnCommand函数，在CFrameWnd::OnCommand中截获的消息会交由VIEW类处理
}
 
MSDN说明：
virtual BOOL OnCommand( WPARAM wParam, LPARAM lParam );
//The framework calls this member function when the user selects an item from a menu, when a child control sends a notification message, or when an accelerator keystroke is translated.
OnCommand processes the message map for control notification and ON_COMMAND entries, and calls the appropriate member function.
Override this member function in your derived class to handle the WM_COMMAND message. An override will not process the message map unless the base class OnCommand is called.

15，LOWORD与HIWORD宏
WORD LOWORD(
  DWORD dwValue  // value from which low-order word is retrieved
);
WORD HIWORD(
  DWORD dwValue  // value from which high-order word is retrieved
);

//The LOWORD macro retrieves the low-order word from the given 32-bit value.
//The HIWORD macro retrieves the high-order word from the given 32-bit value.

16，CFrameWnd::GetActiveView
CView* GetActiveView( ) const;//获取当前视窗口指针（单文档框架中）

17，源文件是单独参与编译的。

from: http://www.manbu.net/Lib/Class9/Sub1/1/9.asp