关于WM上MFC程序对左右软件菜单的控制，可以用win32的方法ShCreateMenu这套逻辑，或者使用CCommandBar这个类（替换掉的以前5.0之前的CCeCommandBar类），先Create然后InsertMenuBar就可以将常规menu资源作为左右软键对应的菜单显示，还可以添加toolbar，虽然看上去有点挤。
由于这种创建菜单的方法，让我误认为只是将win32的menu换了个添加方法，换了个绘图位置，导致后来要实现动态enable,disable菜单项时遇到了挠头的问题。按照常规的做法，在执行逻辑时调用EnableMenuItem(hMenu,IDM_MITEM,MF_BYCOMMAND|MF_GRAYED)，函数调用，返回值以及参数hMenu都没有问题，但执行起来就是没有disabled的效果，google了一通发现国内国外都有很多人提到这个问题，最终也没有个明确的答复，不是说参数hMenu不对，就是说用ShGetMenuXXX的去取菜单，怎么看也不像是真正的解决办法。
后来在一篇动态更新菜单名称的文章中看到貌似WM对左右软键的菜单是作为POPUP MENU处理的，也就不像是win32正统主菜单那样，嗖得丝内，恍然大悟，换用响应WM_INITMENUPOPUP消息的方式，对要变更的菜单项作弹出菜单时的enable disable处理，问题解决，没想到被一个菜单项给杯具了……
C, C++, Obj-C
windows mobile 6环境下的OpenGL ES开发环境设置
Mobile SDK用的是6 refresh附带6.5 chs的rom，IDE用的是VS 2008。
由于google到的相关gles和mobile的开发教程大部分都是对比较早版本的mobile sdk写的，所以可能到了6.0这个时代发生了一些变化导致教程上的某些方法不再适用了（至少我按着其中的做法没有成功…）。这里把能在模拟器上成功运行gles程序的环境设置方法总结一下。
CImage的Draw对Alpha混合的处理问题
WM模拟器上DirectDraw的BackBuffer问题解决方法
上次在参考研究mobile sdk 6.0中自带的DDraw例子时发现在模拟器上跑到创建后备缓冲时由于不支持DDSCAPS_BACKBUFFER而导致程序不能运行，google了一通发现m$网站和其他一些论坛上也有人问过类似问题，得到的答案貌似是说emlator上不能跑DDraw和D3D的程序，要测只能用device，其实只要自己实现一个创建后备缓冲以及用blit模拟flip的方式就可以在模拟器上跑了，并不是模拟器根本就没有实现DDraw，只是没有实现硬件后备缓冲、翻转等操作（其实在现在的PC模拟器上的这2种方式应该也没有什么效率上的差异吧）。
具体代码：
Continue reading…
Nokia官网Sound Mixer Example v2.1中用的wav文件格式
Nokia官网提供的混音示例程序中http://www.forum.nokia.com/info/sw.nokia.com/id/650db12f-06aa-4608-b17a-387b70412304/S60_Platform_Sound_Mixer_Example_v2_1_en.zip.html使用的wav格式为16-bit mono的标准pcm采样文件的纯采样数据部分（这样好处是去掉了wav头信息，减少了一定的容量，坏处就是不能用一般的播放器直接播放），以下为生成该种wav的方法：
Continue reading…
windows mobile中的directdraw
今天说研究一下mobile的游戏开发吧，先从2d这块入手。查到资料说早期是用一种叫做gapi的接口作的，但后来被directdraw取代了，那就用dd吧，好在以前研究过pc的，找了个例子看了看基本差不多，可发现模拟器上无法运行，因为后备缓冲不支持，真是麻烦了啊，调试只能用真机了？
一篇Mac OS下的GL中glFlush和glFinish的区别解释
Q: What’s the difference between glFlush() and glFinish()?
A: OpenGL commands are not executed immediately. Instead, they are submitted to a command buffer that is then fed into to the hardware. The glFlush() and glFinish() commands are both used to force submission of the command buffer to the hardware for execution. glFlush() causes all OpenGL commands currently queued to be submitted to the hardware for execution. This function returns immediately after having transferred the pending OpenGL command queue to the hardware (or software) renderer. These commands are queued for execution in some finite amount of time, but glFlush() does not block waiting for command completion.
[ZT]怎样写参数个数可变的宏？
一种流行的技巧是用一个单独的用括弧括起来的的 “参数” 定义和调用宏, 参数在宏扩展的时候成为类似 printf() 那样的函数的整个参数列表。
#define DEBUG(args) (printf("DEBUG: "), printf args)
if(n != 0) DEBUG(("n is %d\n", n));
明显的缺陷是调用者必须记住使用一对额外的括弧。
gcc 有一个扩展可以让函数式的宏接受可变个数的参数。 但这不是标准。另一种可能的解决方案是根据参数个数使用多个宏 (DEBUG1, DEBUG2, 等等), 或者用逗号玩个这样的花招:
#define DEBUG(args) (printf("DEBUG: "), printf(args))
#define _ ,
DEBUG("i = %d" _ i);
C99 引入了对参数个数可变的函数式宏的正式支持。在宏 “原型” 的末尾加上符号 … (就像在参数可变的函数定义中), 宏定义中的伪宏 __VA_ARGS__ 就会在调用是替换成可变参数。
最后, 你总是可以使用真实的函数, 接受明确定义的可变参数。参见问题 15.4 和 15.5。如果你需要替换宏, 使用一个函数和一个非函数式宏, 如 #define printf myprintf。
参考资料: [C9X, Sec. 6.8.3, Sec. 6.8.3.1]。