windows编程的经验-----------------转载

摘要: tkinter python windows编程

转载自-------http://my.oschina.net/zhoubaojing/blog/189300

1、系统维持一个全局唯一的消息队列。

2、各个创建了window的线程，每个都有且只有一个消息队列，甭管它创建了多少窗口。有多少创建了window的线程，就有多少消息队列。相应就有多少消息循环。

3、鼠标、键盘等硬件靠各自驱动程序将用户的输入搞成message发到系统消息队列。系统有消息循环，将其Dispatch到正确的线程消息队列。GUI线程里也有消息循环，将其最终Dispatch到正确的WNDPROC处理。

4、只要用户有按键行为，必然触发且只触发虚拟按键消息，如WM_KEYDOWN/WM_KEYUP/WM_SYSKEYDOWN/WM_SYSKEYUP。不会产生WM_CHAR消息，WM_CHAR消息永远不会由敲击键盘行为产生。(不带alt的按键称为nonsystem key)

5、消息循环中，一般TranslateMessage与DispatchMessage成一对，就是解决上面的问题，即TranslateMessage的唯一作用就是将WM_KEYDOWN/UP等虚拟按键消息做个解析，比如检测到你按的是A键，就产生一个WM_CHAR消息并放到消息队列里，但正被解析的虚拟按键消息本身不发生任何变化，会继续被传给DispatchMessage去分发，显然，这个新生的WM_CHAR消息只能在以后的新的消息循环里才能得到处理。即只要碰到WM_CHAR消息，它一定是由TranslateMessage函数产生的。当然应用程序主动制造的除外。而且，如果被解析的消息不是虚拟按键消息，那TranslateMessage啥也不干。

6、搞清window之间的两对关系：Parent与Child，Owner与Owned。父子关系中的关注点仅仅要知道：对child进行绘制时，所用的坐标的参考系是其Parent的客户区的左上角，child画在其Parent客户区之外的部分不可见，仅此无它。Owner就是拥有者，被它拥有的东西自称Be Owned。Be Owned的东西永远遮在其Owner之上，当其Owner最小化时，它自身会被隐藏。当其Owner被销毁时，它自身也会被销毁，即Owner是关系到其生死存亡的东西。一般Parent与Owner是同一个window，但理论上是可以不同的。但你自己应搞清这两种关系的区别。

7、鉴于上面这两种关系的重要性，CreateWindow系列函数，都需要指定将被创建的window的Parent。如果一个window没有Parent，或者其Parent是系统桌面Desktop(桌面是一个window，只是它没标题栏而已)，那么这个window称为top-level窗口。

8、CreateWindow与CreateWindowEx的唯一区别是，后者多一个风格参数。CreateWindow里用的窗口风格叫Window Style，以WS_开头；CreateWindowEx里多出来的风格叫Extended Window Style，以WS_EX_开头。CreateWindow内部实现是CreateWindowEx(0, ...)

9、Subclassing在win32 sdk编程里全称是Window Procedure Subclassing.别扯什么子类化，我完全不懂子类化在汉语里是啥意思，也别扯什么派生，这个和派生没半毛钱关系。Subclassing只能在同一个进程里进行，是指更换窗口类或具体窗口的WNDPROC，仅此而已，没有其他。

10、Superclassing。同上，全称是Window Procedure Superclassing.也别跟我扯什么超类化，在我的汉语里完全听不懂。Superclassing的实质是填一张WNDCLASS单子，通过RegisterClass提交给系统注册一下。看到没，这实际上就是构造一个全新的窗口类而已嘛。只是，这张单子的大部分内容，我们是从一张已有的WNDCLASS单子中拷贝过来的，手段是GetClassInfo函数。很显然，既然我们是提交一张新的WNDCLASS单子给系统，我们自然得将单子上的hInstance项、lpszClassName项改成我们自己的。实际上GetClassInfo返回的单子中没有填写hInstance和lpszClassName这两项，也没有hMenu那一项。这里我们自然就得考虑一下menu的问题了，menu有什么问题呢？

如果原先的窗口类没有menu，我们自然不需考虑menu了；如果原先的窗口类有menu，那么在它的窗口类里极有可能有对menu各item项的响应 ，即响应WM_COMMAND消息，case语句比对menu item的id，作出相应处理；如果我们新的窗口过程也处理WM_COMMAND，而且处理完后不交给原先的窗口过程，那我们自然不用担心新的窗口类的MENU的问题；但除了这种情况呢？我们必须保证当有WM_COMMAND消息传递给原先的窗口过程时，能正确运作，那我们就必须将原先窗口类所用的menu资源克隆出一份，其各identifiers保持和原先一致，然后将新的menu资源填到我们的新窗口类单子里。当然，如果新老窗口类在同一个应用程序工程里，共享一份已有的menu资源的话，menu问题也不成为问题，新窗口类只需将那个menu资源填到单子里就可以了，无需拷贝一份menu资源，而且也应该这样干。

很明显，因为我们现在提交了一张新的WNDCLASS单子，所以当然可以使用单子里的cbClsExtra和cbWndExtra这俩玩意儿，这俩玩意儿的意思参考WNDCLASS的MSDN文档。但是要注意了，原先的窗口过程里可能有依赖于这俩玩意的代码，所以为保证原先的窗口过程能正常运作，我们在使用这俩玩意儿时应做到，我们需要多大的额外空间，则给cbClsExtra和cbWndExtra赋值时应指定各自原来的大小加上现在需要的大小，在新的窗口过程里使用时也要注意我们新的额外内存是在原先大小的额外内存结尾处开始的。

11、子控件，也叫子窗口，是窗口。子控件在工作时，可能有时会通知或知会一下它的Parent，通知的方式只有一种，给Parent发消息。发的消息只有两种：WM_COMMAND、WM_NOTIFY。notify比command可以携带的信息量大。比如BUTTON控件被用户单击时，会给其Parent发一条WM_COMMAND消息，消息的lParent参数是这个控件的窗口句柄，消息的wParent高半部分整数值是BN_CLICKED，低半部分整数值是这个控件的id。父窗口想知道自己哪一个子控件被点了的话，只需要在自己的窗口过程里响应WM_COMMAND消息，并依据wParam和lParam这两个消息参数做出正确的判断。所有的父子窗口之间的交互都是通过这种简单的方式，是不是简单得不能再简单了。不同的控件依据不同的事件给其Parent发的是WM_COMMAND还是WM_NOTIFY，消息参数如何解释等等这些东西，都在MSDN的控件自己那一页上可以直接查询到。

12、自绘。我不知道“自绘”这个词是哪个傻B发明的，反正它让我长久以来一直没搞懂啥叫“自绘”。“自绘”英文是Owner-Draw。看到没，是Owner在Draw，Owner是啥，Owner是控件的拥有者，不是控件自身，所谓的Owner-Draw就是控件窗口需要绘制显示在屏幕上时，会给其Owner发一条WM_DRAWITEM消息，通知其Owner，让它负责把控件自己给画出来。这尼玛是自绘吗？？？是自己绘制自己吗？？？明明是让别人画自己！