re: GUI框架：消息检查者 Richard Wei 2012-09-04 09:57
mark下
对于如何关联HWND和CWnd常用有3种方法:
(1)MFC的Map,就是博主上面用的
(2)把CWnd指针放在CreateWindowEx的最后一个参数里，在回调WM_NCCREATE里从CREATESTRUCT里取出来，再保存CWnd*到SetWindowLong(GWL_USERDATA)中，后面其他消息就直接取出CWnd*调用
(3)ATL的Thunk机制
第一种方法容易理解，但是低效
第二种方法把CreateParams和UserData用掉了，别人没法再用了，通用性不是很好
第三种方法简单高效，但是会涉及到机器码
支持一下,不过即使有D3D和WPF的经验,做这个东西也不是容易的事
re: C++中实现回调机制的几种方式 Richard Wei 2012-08-28 17:43
借助C++11种的function, 可以让我们无差别的对待普通函数和类成员函数，实现delegate会容易很多
re: 关于PostMessage在多线程中的内存释放问题 Richard Wei 2012-08-21 11:19
@Dragon
是的，你可以试下连续Post 100条Message，然后结束结束接收线程，所有的消息就都被丢掉了，自然就内存泄露了。
re: 共享个人写的一个截屏小工具 Richard Wei 2012-08-21 10:56
@bukebushuo
可以截层窗口, 不过截硬件加速的视频不行，那个需要用API Hook.
re: 关于PostMessage在多线程中的内存释放问题 Richard Wei 2012-08-20 21:04
PostMessage只是把消息放到线程消息队列，线程退出时并不保证队列中的所有消息都已经被处理，所以博主上面的解决方案仍然会有内存泄露。
re: 如何学习WindDbg Richard Wei 2012-08-15 17:50
@zaccheo
VS2008 Release版默认编译选项就是生成PDB符号的，在有符号的情况下用WinDbg调试程序其实不需要什么汇编知识。
re: 不知道能不能这里前辈交流一下（编程技术讨论吧） Richard Wei 2012-08-15 14:21
博主不错，比我毕业时厉害多了。
re: 如何判断一个C++对象是否在堆上 Richard Wei 2012-08-13 14:30
上面关于对象是否在堆上的判断应该是不对，因为堆内存不是连续内存，内部是通过类似链表的结构来实现的，<<软件调试>>里有相关介绍，也可以通过WinDbg的 !address 命令查看内存分布
re: 堆栈桢的生成原理 Richard Wei 2012-07-20 15:31
据写过调试器的朋友指点，调试器会尽量减少代码运行时的干预，所以上面关于函数调用时调试器保存调用现场的猜测，应该是不正确的。
调试器更多的可能是根据PDB文件信息来计算推理的，如果没有PDB文件，它就只能猜测，很多堆栈信息就会出错了。
据说<<软件调试>>里有相关介绍，回头看下, 希望这篇博文不要误导他人。
re: 开源一套DirectUI界面库 Richard Wei 2012-07-20 08:36
@oksbsb
不知道你那边为什么不行，我试了下还是可以下的， 代码已发。
re: LingosHook : 值得纪念的一天 Richard Wei 2012-07-17 09:22
恭喜一下。
一直也想搞自己的软件，无奈一直没时间。
如果要用显试调用类，建议还是用接口方式吧，导出一个CreateInstance(interface** ppInterface)就可以了，简单又方便，具体参考COM
re: 开源一套DirectUI界面库 Richard Wei 2012-07-16 19:43
@圣
资源压缩和delegate方式的事件处理加上去也不难。
这套东西只是半成品，本来想写给自己用的，可看了WPF后，觉得没必要写了，微软已经把我们想做的东西做到了极致...
re: 跨模块传参数的教训 Richard Wei 2012-07-16 10:04
@zuhd
恩,跨模块返回一个未初始化的CString会有同样的问题,
所以跨模块还是用C语言的字符串方式比较保险。
re: 开源一套DirectUI界面库 Richard Wei 2012-07-11 11:03
@先锋
不用WTL，ATL就够了。
相信这套东西会给真正研究过DirectUI的朋友很多参考价值。
re: 开源一套DirectUI界面库 Richard Wei 2012-07-11 11:00
@圣
真想骂人，你看过代码吗？？ 别弄脏了这里。
re: 用Windbg解决一个Bug Richard Wei 2012-07-08 10:08
@weolar
是的, 理论上Vc和Windbg用的是相同的的调试引擎,但是我试了些VC的command,设置断点的bp和察看堆栈的kv都不支持，不知道怎么回事。
另外windbg本身很小，在QA机器上安装也很方便。
re: 如何减小Exe, DLL 的大小 Richard Wei 2012-07-07 15:23
感觉另外还有应该尽量少用全局和静态变量，他们会被直接编译到PE文件的数据(.data, .rdata)段中；另外图片等资源也挺耗空间，简单的图片可以在运行时自己画出来。
re: MUILIB题外话:Windows真的没落了吗 Richard Wei 2012-07-04 14:53
@万连文
不扯了，我最初的本意只是提醒博主：他想靠现在的基于GDI的DirectUI赚钱会很难.
re: MUILIB题外话:Windows真的没落了吗 Richard Wei 2012-07-04 13:26
@万连文
我也看好HTML5.
对于Native应用,我觉得正如Mac上的Cocoa，windows上趋势则是WinRT和Xaml。
设计好的界面引擎的确应该和底层Rendering的方式无关，无论GDI，D2D(D3D)，或是OpenGL，但是3D和2D接口是如此不同以致现时中很难看到他们的统一。
说Windows没落或许有点过了，但是windows上传统桌面应用开发的减少现在却是趋势.
至于我那套界面，高手眼中的确是玩具程序，初学者或许可以拿来入门.
re: MUILIB题外话:Windows真的没落了吗 Richard Wei 2012-07-04 11:28
@bukebushuo
微软不可能修改传统GDI接口的内部实现来支持硬件加速, 因为修改没那么容易，那样也意味着所有老的基于GDI开发的应用程序都要做兼容性测试. 即使要增加支持硬件加速的接口,也会以新的方式提供(比如D2D)。这里最关键的是微软有了自己的Xaml界面的标准， 外面的人这块市场很难进入了。
我只是善意的提醒...
re: MUILIB题外话:Windows真的没落了吗 Richard Wei 2012-07-03 21:39
本不想回复了,想想还是回复下吧.
我感觉经过这么多年的发展，windows的桌面应用软件已经开始饱和，所以windows上的新应用程序也越来越少，大部分是已有程序的维护和升级。当然作为主要的办公平台，在没有找到新的办公方式之前，windows传统的桌面应用还将在一定时间内长期存在。
随着XP的淡出，基于GDI/GDI+开发的界面也会逐步被支持硬件加速的D2D/D3D应用所取代，传统的窗口控件机制也将逐渐退出，所以个人在这时基于GDI/GDI+开发DirectUI已经没有多少意义。而微软Xaml方式的界面（WPF, Metro )正逐步成为新的Windows界面标准，所以我相信微软以后传统桌面下也会有支持触摸、支持自动测试的Native版本的WPF。
至于移动领域，我个人觉得微软可能会通过WinRT实现PC, win8平板，windows Phone开发方式的统一。
很多开发人员(包括我)都不愿意放弃自己辛苦学习的已有技术，但是我不得不说GDI过时了...
re: MUILIB-可视化界面编辑器功能测试版完成 Richard Wei 2012-07-03 09:27
re: MUILIB-可视化界面编辑器功能测试版完成 Richard Wei 2012-07-02 19:14
如果想赚钱，windows传统桌面下界面应用已经没有多少前途，尤其是基于GDI的，希望不要在错误的道路上越走越远； 当然如果是兴趣，玩什么的都没错。
re: 关于编程的胡扯 Richard Wei 2012-06-22 09:37
不错，正在为平台而烦恼，支持一下
re: 远程线程入门 Richard Wei 2012-06-20 23:53
@饭中淹
不依赖汇编重定位的代码注入也做了下尝试，发现挺好用的，测试代代码也放上去了，单纯用Ｃ＋＋就可以了，就是注入代码大小不太好算。
re: 远程线程入门 Richard Wei 2012-06-20 21:30
@饭中淹
是的，我们可以先在目标进程中把需要的数据分配好，然后通过线程参数把地址传进去，这样可以避免全局变量。
关于代码注入，这篇文章不错：
http://www.vckbase.com/index.php/wv/1580
re: 为什么设计模式在C++社区没有Java社区流行? Richard Wei 2012-06-20 11:12
@毕达哥拉斯半圆
不错， 新加了
(6)C++支持多种编程模型，包括面向过程，面向对象，基于对象，泛型编程等，设计模式主要是基于面向对象的，而Java只支持面向对象开发。
re: 从自己的角度来看人生路 Richard Wei 2012-06-20 10:22
博主还很年轻
re: 跨越Win8 Metro开发 Richard Wei 2012-06-15 16:56
@空明流转
是的，微软做了我们想做的，如果Desktop下也有Native的Xaml UI, 那么自己开发DirectUI就没多少用处了。
re: 为什么设计模式在C++社区没有Java社区流行? Richard Wei 2012-06-15 16:52
@leolai
是的，设计模式在比较大型的C++开源项目中用的还是比较多的，比如网络库ACE，界面库QT，游戏引擎Orge, Irrlicht等
re: 跨越Win8 Metro开发 Richard Wei 2012-06-15 16:43
@leolai
恭喜你，看来Metro开发对你没多少障碍
re: richedit研究02 – 大纲 Richard Wei 2012-06-15 09:48
关注, Win7下例子跑不起来
re: 为什么设计模式在C++社区没有Java社区流行? Richard Wei 2012-06-15 09:24
@春秋十二月
恩，你长大了 :)
re: 难以割舍的二段构造 Richard Wei 2012-06-14 16:37
支持一下，C++里我们一般把分配内存和简单的初始化工作都放在了构造函数里，而把一些复杂的工作放在一个单独的初始化函数里，这样的话比较灵活。如果觉得使用不方便，可以自己封装一层，也就是所谓的RAII了。
re: 如何定义变长的TLV结构体？ Richard Wei 2012-06-14 16:23
windows API里很多结构体的第一个字段一般都是UINT cbSize， 就是为了以后可以扩充。
re: 为什么设计模式在C++社区没有Java社区流行? Richard Wei 2012-06-14 11:16
@春秋十二月
看来你没看懂, C or C++ :)
re: 软命令接口的适用场合 Richard Wei 2012-06-13 21:08
@jacky
确实应该是facade, 只留意大概读音，没想到拼写错误。
多谢指正。
re: Windows 8 基本概念 Richard Wei 2012-06-13 13:50
最近也开始关注Win8开发，无奈一直没法入门，感觉从Desktop开发转换到Metro开发的几个门槛是:
(1)C++/CX语言本身的学习及语言背后的原理。
(2)Metro模式背后原理的学习，搞清楚它和传统Desktop的交互和关系。
(3)WinRT类库的学习， 最好对整个WinRT的体系结构进行系统的介绍。
(4)通过XAML开发UI的学习， 这个东西对很多WPF的程序员来说很容易，对其他人来说就没有这么简单了。
(5)D3D的学习，以及D3D和XAML UI交互的学习，开发一些高端产品最后还是需要在XAML里嵌入很多自己rendering的东西。
我觉得当上面的层次都掌握了，才可以说自己真正懂Metro开发了。 希望搂主可以按上面层次作些介绍。
re: 软命令接口的适用场合 Richard Wei 2012-06-13 13:29
@华夏之火
这个怎么说呢，Faced模式强调的是一个复杂系统对外有一个统一的入口； Bridge模式强调的是分层的概念，将抽象层和实现层分离，二层可以分别独立的变化。感觉上面的"软命令"方式，从对外暴露的接口的简单统一性来说比较符合Faced模式；但是从内部实现来说，你要理解成同一消息可以有多种处理方式，Bridge模式也可以。
re: 一道考验你设计能力的C++编程题 Richard Wei 2012-06-13 13:06
@leolai
同意。
一般来说，除非某些设计模式你现在确实适合使用，或是你能预测到今后可能的变化，你才应该使用该模式。
否则还是只要满足当前的需要就够了，等确实有新需求时再考虑重构你现有的代码。比如上面有的 去边框(unframe), 用XML格式打印图片的组成结构 等，都是新需求。
re: C++11新特性不完全测试 Richard Wei 2012-06-13 10:39
@华夏之火
恩，大家本来对concept期望很大， 如果真的有concept， C++11就完全是一门新语言了。
re: 敢问路在何方? 一个老程序员的真情告白！ Richard Wei 2012-06-12 22:09
佩服楼主，楼主还在杭州吗，我也在杭州
re: 消息发送VS设计模式 C++沉思录的一练习题的另解 Richard Wei 2012-06-12 20:26
这个例子源自《C++沉思录》，同时也建议楼主看一下这本书，它会告诉你Why C++, how C++?
re: 消息发送VS设计模式 C++沉思录的一练习题的另解 Richard Wei 2012-06-12 19:48
当然，看了楼主一些博文，我还是挺佩服楼主的，就是希望楼主不要痴迷于windows 消息处理函数的设计机制。
re: 消息发送VS设计模式 C++沉思录的一练习题的另解 Richard Wei 2012-06-12 19:42
既然原文是指我的博文，我来尝试评价下楼主上面的实现,如果有不正确的地方，请指正:
(1)楼主用C的方式来模拟C++的虚函数，除了以后难维护外，得到了什么好处?
(2)Windows用软命令的方式来实现消息处理函数, 是因为消息类型太多，而且方便以后扩展新消息，我感觉用的恰到好处，但楼主这里也用这种方式就感觉有点过了。如果都按照这种方式，无论什么类都只要一个CommandHandler函数就够了。我个人觉得一个用途明确的接口才是优雅的设计。
(3)请问楼主如何处理去边框(unframe)的情况,如何知道当前的对象是不是支持unframe?
(4)楼主有没有发现main函数里使用你的接口时特别别扭(比如这个代码CHorseDecorater hors(pict1.m_Imp, pict2.m_Imp); pict1.Print(cout);), 我觉得良好的设计，应该让使用的人觉得很舒服。
(5)楼主看起来挺讨厌设计模式，但是在某些情况下用正确的设计模式确实可以让你的程序有很好的可扩充性，毕竟它们是大师智慧的结晶。
re: 一道考验你设计能力的C++编程题 Richard Wei 2012-06-12 11:12
@Simon
呵呵, 夸我还是骂我？