昨天说干就干，打开尘封很久的工程，添加一个窗口，把那几张现成的图片抠过来，然后计算一下桌面工作区大小，把窗口放在桌面右侧，像是侧边栏的样子。结果一开始，什么都没有显示出来，这是相对比较麻烦的出错情况，因为根据之前使用GDI+创建异形窗体的经验，这时候任何地方都有可能是出错的地点，所以要找出原因就要费点工夫。仔细对照之前写的代码，一点点的修改，终于能让它显示出一个窗口了，但是窗口仍然是窗口，没有按照预想的那样把png图片显示出来，并按图片渲染窗口形状。最后发现是在创建窗口的时候，因为心急，直接把窗口设置为桌面的子窗口了，如果把那几行代码去掉，就都正常了。经过这次实践发现，用GDI+实现异形窗体可以随意缩放窗口大小的，一般说来，要把窗口调整到需要的尺寸，通常是大于或等于图片原始大小，这时再把图片按窗口大小画上去就可以了，这种特性在绘制侧边栏的时候有用，比如可以只有小小一张图片，但侧边栏可能很长，就直接这样拉伸了。
能显示出侧边栏的底座了，就要开始考虑接下去怎么做了。鱼鱼和雅虎是两套不同的方案。鱼鱼只是能计算一下各个widget的大小尺寸，根据当前侧边栏上停靠的widget计算出其他widget停靠的位置。雅虎的稍微复杂点，它的一个widget的可见内容分为两部分，一部分是在桌面上散布的体现真正内容的widget；另一个部分可算是widget图标，停靠在侧边栏上。这样对于widget开发者来说，刷新界面时需要刷新两部分的隐性要求比鱼鱼要大，鱼鱼的只要刷新widget主窗口就可以了。当然雅虎的也不是强制要求一定要同时刷新图标，只不过有这样的表现的机会，为什么不利用上呢！
今天又偶然发现，雅虎的widget也使用了跟chrome类似的sandbox技术，从任务管理器上看多显示一个widget，就会多一个YahooWidgetEngine.exe进程，数完widget数目后，还多一个进程，我猜应该是侧边栏的。自从见到chrome后，我就莫名地对这种sandbox做法很有认同感，据说我们部门在北京的分部做的一个测试用例开发执行工具也是用的这种方式。不过相比Unix-like系统，在Windows下创建进程的开销相比就大了点，随便开了十来个widget看看，有两个进程内存占用10MB多一点，其他的都是1MB多，我估计如果它若是使用单片式结构的话，同样开这么些widget，占用的内存数应该没有这些的总和多吧。再说说由此引出的进程间通信的问题，毫无疑问，进程间通信的开销明显要比进程内通信的大，在Windows上应该更突出，不过对于像widget这种应用，进程间通信的频率和数量应该都不大，影响也倒不会太大；其次是从程序开发的角度讲，进程间通信应该更难使用，尽管Windows确实也提供了不少机制，但终归是难用啊。最后还有另外一个问题，对于稍微有点常识的Windows用户来说，这种方式是否也能得到他们的认同呢，某一天打开任务管理器突然发现有这么多相同名字的进程，会不会觉得反感呢，至少我是看到有人这样非议过chrome的。
再说点WTL相关的问题。昨天发现一个用WTL写的应用，在VS2005下编译，Debug下好好的，到了Release下连编译都通不过，删了一些怀疑的代码，还是编译不过，最后从WTL的源代码看到，原来只要在工程设置里把是否使用ATL的最小CRT关掉，就没问题了，之前也有因为这个设置引起奇怪的编译不过的问题，缺少官方正式支持的东西就是累啊，这WTL光是这些头文件包含，宏定义，就让人头大了。
最后八卦一下Inno setup，发现有时居然会out of memory，这时把里面两个压缩级别选项都从ultra改成max就好了，不知道是不是Bug？
支付宝扫一扫
微信扫一扫