备注:Rimi是我们用的一个分布式机制。

在进行设备树(也就是一个CTreeCtrl控件)更新修改的时候,遇到了一个比较bug的问题。

为了提供更好的用户体验,甲方希望设备树更新之后滚动条位置能够保持与更新前一致。设备树的更新过程是这样的:更新消息来自Rimi的通知机制,类似于函数回调,客户端在收到消息之后调用Rimi的对象方法来获取新的设备树信息,然后更新树。乍看之下,要完成这个修改好像很简单,只要更新前先记录滚动条的滚动位置,更新后还原位置,如果更新后滚动条滚动范围变化了还要微调一下位置,逻辑上来讲就这么几个步骤。

我一开始也是按照这样的思路,GetScrollPos()获取当前滚动条的滚动位置,然后更新树(先删除所有节点再逐个添加,其他省略...),GetScrollRange()获得新的滚动范围,最后SetScrollPos()将旧的位置与滚动范围最大值中最小的一个设回去(这里用到的ScrollBar是CTreeCtrl自动产生的,注意不是两个控件,这里调用的函数都是CTreeCtrl的方法)。但实际效果是,树更新后滚动条滚到准确的位置,但树的视图到了最顶,点击一下滚动条的那个方块才能回到之前的位置。也就是说,滚动位置的更新与树的视图分离了。

之后,我一直以为是我控件的方法用错了,对着MSDN和CSDN纠结了很久。最后忍无可忍,自己写了个测试Demo,里面就一Dialog,一CTreeCTrl,树上随便加了些东西,然后又一按键,按键后会重新刷新树,再滚动到原来的位置,结果居然是对的,视图跟着滚动条的位置变化了。为了更好的模拟设备树节点增删的效果,我在按键响应上又作了处理,按一下重刷树的时候会隐藏几个节点,再按一下这些节点显示出来,滚动位置按照客户端里面的一个处理方法,结果居然也是正确的。问题变得玄乎了!

无意间发现客户端里面有个手动刷新设备树的快捷键,估计是当年pb做调试的时候留下来的。快捷键的响应直接调用更新树的函数,重刷后的显示出人意料地是对的。比较一下两种更新方式的过程:

Rimi:   通知到来—>更新树(Rimi回调函数,Rimi自己维护了一个线程池,远程调用在被调用端的发起者都是Rimi自己的线程)
快捷键: 按键响应—>更新树(MFC消息处理函数)

更新树所用到的是同一个函数,但调用者却是不同的。因为Rimi用了boost::function,那我也在按键响应的时候对要调的函数用function来包装一下,造成两者在调用栈上调用的函数、顺序大部分是一致的,只有最底层不同,一边是Rimi,一边是MFC消息传递。

后来jianhao说,以前在Rimi的回调函数里面调Rimi对象的方法出过问题,然后我又顺道回忆起之前zxb在Rimi函数(还是对象方法)里面调system()也有问题。

难道说Rimi线程就是“万恶之源”?好吧,我把更新代码移到另外一个线程里面,Rimi回调的时候唤醒更新线程,更新后视图还是不能跟着滚动位置变;将快捷键的响应也修改一下,自己不作更新,也是唤醒更新线程,这个方法也变得不灵了,囧!这可以说明问题跟Rimi线程无关。

难道说线程调用才是“万恶之源”?把之前做的那个Demo小改了一把,线程做刷新,按键响应只唤醒更新线程,果然不灵了!上网google了一把,关键字“mfc 线程 操作控件”,首先映入眼帘的是《MFC中跨线程操作控件会不会出现像C#中的异常问题?》。这时候我也不关心这个帖子的内容了,线程操作控件有异常是吧,那就不用线程做咯!这时候我才回想起WIN32里面有自定义消息这玩意,MFC里面给定一个消息ID,ON_MESSAGE绑定一个处理函数,PostMessage或SendMessage来发消息,然后由WIN32自己的消息循环来调用处理函数,这样应该是可以保证用非Rimi线程来更新设备树的。再一次把Demo小改了一把,按键响应Post一个自定义消息,消息处理函数做刷新,结果是对的;再改,按键响应唤醒线程,线程里面Post自定义消息,结果也是对的。

原以为是控件使用问题,又以为是Rimi不兼容问题,最后实质为MFC跨线程使用控件的问题。其实我也不清楚这是不是真正的问题,毕竟我MFC既不懂又用得少。That's all!

最后附上我的测试代码
http://www.cppblog.com/Files/neverwinter/testtree.rar