好了，改了之后的代码复杂很多，当然了，功能也比之前的多了很多，但是还是那句话，大概结构没有变，一个while循环、一个接收用户输入部分、一个响应用户操作部分。（看完代码和图的同学，或者说有Win32编程基础的同学，到现在为止，可能已经看出这是个啥意思，我们暂且先不说，听我慢慢道来O(∩_∩)O~）
现在我来说说改了之后的代码还有哪些地方的不足：

1.每个Rect对象之间无法通信，因为各个Rect对象之间是相互独立的，每个Rect对象在响应用户输入（执行RectProc，下同）的时候不能影响其他的Rect对象，因为你根本不知道另外的Rect对象在哪、什么状态。
2.在响应用户输入的时候，也就是while循环体执行期间，我们不能改变while循环条件，让循环结束，意思就是，现在这个线程，有两种情况退出，第一种就是用户直接输入“QUIT”，第二种就是强制关闭程序，后者明显不可取，那么前者一种方法能满足我们的需求吗？答案是不能，现在考虑这种情况：在线程运行期间，所有存在的Rect对象中有一个是主Rect，也就是说，这个主Rect对象跟其他不一样，当这个主Rect对象被用户关闭后（RS_KILL），最好的效果就是，整个线程结束。因此，在主Rect对象处理RS_KILL信号后，应立马“模仿”用户向线程再发送一个“QUIT”字符串，让while循环下一次退出。
3.Rect对象既然是用户主要操作的目标，那么就应该允许我们在Rect类上继承新的类，来实现更丰富的效果，而且，新扩展出来的类也应该像Rect类一样响应用户输入。
4.同样，Rect类对象的一举一动，势必会影响另外一些对象，所以，Rect类应该加上一些事件（此处事件为.net中的Event，它与Windows事件的区别稍后会讲）。
5.在Rect类对象响应用户的某一次操作后，可能需要再次通知自己进行其他操作，比如一个Rect对象在响应“改变位置”这个信号之后，立马需要显示自己信息，也就是说在处理完RS_POSITIONCHANGE信号后，立刻需要给自己发一个RS_SHOWINFO信号，它才能显示自己的信息。这就出现一个问题，“信号”会产生“信号”，这个过程完全不需要用户区操控，当然，用户也无法去操控。
6.最后，不知道诸位发现没有，用户的输入与Rect对象的响应是（也只能是）同步的，啥叫同步？简单来说就是，A做完什么之后，B才能行动，或者等B行动完后，A才能继续。只有等用户输入后，GetSignal方法才能返回，Rect对象才能做出反应，同理，只有Rect对象响应完成后，用户才可能继续输入，一次输入一次响应，输入没完成，就没有响应，响应没完成，用户也不能输入。理想情况应该是这样的：用户在想要输入的时候就可以输入，而不用去管Rect对象有没有响应完成（DispatchSignal返回），当然，在这种情况下，用户的输入仍然会陆陆续续的被响应。
分析一下上面6条，其中1、2、5条其实意思差不多，就是在while循环体执行期间，需要“模仿”用户输入，然而现在的情况是，GetSignal方法是“主动型”的，只有它主动去接收用户输入，它才会有结果，当它没有准备好，就算有输入，也不会被接收。这样看来，我们只有增加一个类似“缓冲区”的东西，不管GetSignal有没有准备，所有的输入信号全部存放在这个缓冲区中，等到GetSignal准备好获取输入信号时，直接从这个缓冲区中取得。
说到“缓冲区”，我们第一应该想到用“队列”，不错，就是队列！我们来看一下MSDN上对“队列”（Queue类）的解释：
Queues are useful for storing messages in the order they were received for sequential processing. This class implements a queue as a circular array. Objects stored in a Queue are inserted at one end and removed from the other.
大概意思就是队列一般用于存储需要按顺序处理的消息。
第6条其实也可以用队列来实现，用户不停地向队列输入，而不用管Rect对象是否立刻去响应，队列起到一个缓冲的作用，当然，如果这样设计的话，用户输入和Rect对象响应输入应该不在同一线程，这就要用到多线程了。
第3、4条其实就是OO中的继承、虚方法引起的“多态性”，以及.net中常用到的Observer模式，用Event很好实现。
升华：
经过分析，Rect类改为：(虚方法以及事件只举例定义了两个，现实中应该有很多个)

再分析一下，代码修改之前提出的6条不足，基本上全部解决了
1.在Rect对象（或其派生类对象，下同）处理信号的时候，只要知道任何一个相同线程中的其它Rect对象的ID，那么就可以利用ZZThread.SendSignal()向其发送信号。
2.同理，在某一Rect对象（我们在这成为主Rect）关闭的时候（处理RS_QUIT信号），它可以通过ZZThread.PostQuit()方法向循环发送退出信号。
3.通过允许Rect类被继承，就可以实现多样化的效果，响应用户输入不再仅仅只是Rect类了，还可以是Rect的派生类。
4.通过向响应者（Rect类）添加事件（Event）的方法，外部其他Rect对象就可以监听到事件的发生，做出相应响应。
5.与1相似，在处理某一信号的时候，完全可以通过ZZThread.SendSignal方法将ID参数设为自己的ID，向自己发送一个信号，这就可以达到“在处理完一个信号后紧接着向自己发送另外一个信号”的功能。
6.通过增加信号队列和一个专门接受用户输入的线程（以上示意性代码中未给出），完全可以达到“让用户输入和Rect对象响应”异步发生。
以上6条确实完美解决了，现在继续考虑几个问题（你们可能知道改完之后的这个东西肯定不会是我们最终想要的，因为它貌似跟我要讲的Winform几乎没有任何联系，所以，继续考虑下面几个问题）。
（由于每个问题跟上一个问题有联系，所以我依次给出了问题的解决办法。）
1. 这个只能在一个线程中使用，也就是说，同一个程序中，只能存在一个这样的线程，因为ZZThread类是个静态类，所有的成员也是静态的，如果多个线程使用它的话，就会全乱了。举例看下面：
Thread th1 = new Thread((ThreadStart)(delegate(){
ZZThread.Main();
}));
th1.Start();
Thread th2 = new Thread((ThreadStart)(delegate(){
ZZThread.Main();
}));
th2.Start();
th1与th2两个线程中，用到的signalList、allRects是同一个，两个线程中的while循环也是从同一个信号队列中去取信号，然后分配给同一个Rect对象集合中的对象，虽然可以做一些同步“线程安全”的处理，但是仍然有问题，仔细想一想（比如发送RS_QUIT信号想让本线程退出，到底哪个退出不确定）。因此，理想情况应该是这样的：每一个线程有自己的信号队列（signalList），有自己的Rect对象集合（allRects），有自己的while循环和自己的DispatchSignal方法，换句话说，两个线程之间不应该有瓜葛，而应该互不影响，相互独立。（当然，除了这些，两个线程理论上可以有其他联系，后面会提到）。
解决方法：
既然ZZThread类是静态的，那么我们就可以把它设置成非静态，每个线程对应一个ZZThread对象，这样线程与线程之间就不会有影响，每个线程都有自己的信号队列、自己的Rect对象集合以及自己的while循环和DispatchSignal方法。当然，如果这样处理的话，就应该考虑怎么确保每个线程拥有自己的ZZThread对象，就是说，怎么保证一个线程能找到与它对应的ZZThread对象？很简单，每个线程都有唯一一个ID（整个系统范围内唯一），可以定义一个Dictionary字典，在每个线程中要使用ZZThread对象的地方，先根据线程ID（这个可以随时取得，只要在同一线程中，ID肯定相同）查找字典，如果存在，直接拿出来使用，如果不存在，说明还没有创建，那就新建一个ZZThread对象，加到字典中，将新建的ZZThread对象拿来使用。这样的话，在每个线程的任何一个地方要使用ZZThread对象的话，都能通过该方法取得同一个ZZThread对象。但要考虑怎么去维护这样一个字典？
2. ZZThread类不能直接暴露给使用者。还是考虑多个线程的情况，ZZThread类中的while循环入口（之前一直是Main方法）、以及诸如像PostQuit、SendSignal等（后面可能还会增加）都是public类型的，如果ZZThread直接暴漏给使用者，使用者完全可以在一个线程中使用另外一个ZZThread对象（注：1中的解决方法只解决了“怎样让一个线程正确地使用同一个ZZThread对象”，并没有解决“一个线程只能使用一个ZZThread对象”）。
解决方法：
一个很好的解决方法就是将“精髓部分”封装起来，封装成一个库（或者模块、框架随便叫），只对外开放必要的类，而像ZZThread这样的类也就没必要开放，最关键的是，1中提到的字典也不应该对外开放，使用者的不正当操作很可能破坏该字典。
3. 考虑一种情况，Rect对象在响应信号时（RectProc执行期间），耗时时间太长，即DispatchSignal方法长时间不能返回，也就是说，长时间不能再次调用GetSignal方法，导致线程中信号大量累积，不能及时处理，因此用户的输入也不会及时得到响应，造成用户体验明显下降，这时候改怎么处理？
解决方法：
既然DispatchSignal方法不能及时返回，导致信号队列的信号不能即使被处理，那么我们可以在Rect对象处理信号的耗时操作中（RectProc执行期间），执行适当次数的while循环，也就是说，在一个while循环体内，再次执行一个while循环，及时处理信号，这就是嵌套执行while循环了，当然，内部的while循环跟外部的while循环有稍微差别，即内部while循环每次就执行一次，执行完后，继续做其他的耗时操作，如果需要大量循环处理一个内容，可以在每次循环结束后调用一次while循环，保证信号队列的信号能够及时处理。上一张图，看得明白一些：

另外，还有一种内嵌的while循环，它不止执行一次循环就退出，而是当某种条件为真时，才退出，这种现在涉及不到。总之，我们可以看出一个线程中可以有多个while循环来处理信号，这些while循环大多是嵌套调用的（不排除这种情况：一个while循环退出后，接着再跟一个while循环，这两个while循环完全相同，但这种出现的几率很少，以后讲到Winform相关的时候我会谈到这个东西的）。由此可以看出，一个线程中的while循环有好几种，所以我们需要每次调用while循环的时候加以区别。
4. 由1中得知一个应用程序可能由好几个需要处理信号的线程组成，每个线程之间相互独立，由2中得知，需要将不必要的类型封装起来，只向用户提供部分类型，使用者利用仅有提供的公开类型就可以写出各种各样自己想要的效果。既然要将代码关键部分与用户可扩展部分分开，那么现在就要分清哪些东西不需要使用者操心、而哪些则需要使用者操心。
解决方法：
前面说过，ZZThread类肯定不能公开，也就是说while循环、信号队列、Rect对象集合都不公开，Sgl枚举和Signal类也没必要公开，因为使用者根本不需要知道这些东西（从框架设计角度，这些东西也不是公开的），使用者唯一需要了解的就是Rect类，使用者知道了Rect类之后，就可以从该类派生出各种各样的子类，在子类中重写Rect的虚方法，然后注册子类的一些事件等等（这要求必须提前将Rect类中需要处理的信号考虑完整，也就是说一切信号类型在Rect类中全部都有默认处理，而且还要完善虚方法，子类才能重写任何一个它想重写的虚方法）。另外，如果ZZThread类不公开，那么使用者怎么让线程进入while循环？因此，需要定义一个代理类，该代理类跟普通类不一样（见代码），然后将该代理类公开给使用者。
精包装：
框架部分
（1）ZZAplication代理类