道，深藏不露，难以理解。
Archive for 六月 2010
这段时间花了很多时间在修改BUG上。有一些BUG可以看得出是以前的人在实现时仓促留下的。有时我们自己在巨大的时间压力之下也很容易会留下这种“缺陷”（可能当时还不是BUG），但是自己心里很清楚，这个地方在以后极容易出BUG。
实现功能往往是最容易的，保持代码的“干净”，架构的“纯洁”才是不容易做到的。
想想在一个版本反复的被测试打回，已经Delay了多日后，当修改一个BUG时，明明需要对架构进行一次重构，增加一个抽象。可又有多少人还会这样“大动干戈”，或者就把已有的代码COPY一下，再改一改就算了。越是在发版本的前夕，越是容易埋下“地雷”，留下隐患。所以我总是最担心最后改BUG那个阶段。
如果需要在用户改变窗口大小时进行限制。比如限制窗口的最小尺寸/最大尺寸，应该处理窗口的WM_GETMINMAXINFO消息。具体的使用方法请参考MSDN。
如果在改变大小时要实现特殊的逻辑，比如像VIM编辑器，在改变窗口的高度时总是以行高为单位，以避免窗口会出现半行文字。这个可以处理窗口的WM_WINDOWPOSCHANGING消息。这个事件在真正改变窗口大小之前发送，修改其中LPWINDOWPOS中的cy和cx值就可以限制窗口大小。
上面的这些处理千万不要放在WM_SIZE中，虽然也可以实现但会导致窗口出现闪烁。
如果还需要知道用户是通过拖动窗口哪个边界来改变窗口的大小。比如说如果当前窗口只显示了一个大图的一小部分，如果用户拖动窗口上边框来改变窗口的大小，这时应保持窗口下部显示内容相对不变，同样如果用户拖动窗口的左边框来改变窗口的大小，应该保持窗口右边的显示区域不变。不过我发现大多数软件都没有处理这个逻辑，比如PhotoShop。它总是保持显示内容左上角的位置不变，这样如果中在显示大图的一部分时拖动窗口的左边框、上边框或是左上角，整个显示的内容会抖动很不爽。
在改变大小时要感知用户是拖动了窗口的哪个边框来改变大小的，可以处理窗口的WM_SIZING消息，该消息的wParam参数指明了窗口的哪一条边或哪一角的位置改变了。（注意：WM_SIZING只在用户交互式的改变窗口大小时才触发，一些间接的改变大小的行为：如窗口复原，平铺窗口，只会触发WM_WINDOWPOSCHANGING。）
最近需要在产品中用到windows平台的管道通讯机制，因此对管道进行了一番考察，将相关的信息记录如下（只记录要点，如何使用的代码请看MSDN上的例子）：
管道是windows平台下的一种RPC机制，不但支持同机器的，也支持跨机器的访问。总之一句话，linux下的管道机制，直观好用，功能强大。windows的管道使用相对复杂，有一些“出乎意料”的地方。
这里对各种时间值的格式和相互转换做了个总结。非常有用，转一下做个记号。
原文（http://blogs.msdn.com/b/oldnewthing/archive/2003/09/05/54806.aspx）。
这段时间加班加得比较多，零碎一点的时间都被“烽火战国”给消灭了。冷落我的BLOG好长时间了。
正好这次写新UI库还是累了不少心得，要抽时间都记下来才行。
另（http://t.qq.com/KylePan）这是我的微博，有的可以加个。