200分求解：用BCB制作的ocx，在vc的子对话框上使用，ocx失去焦点后，程序就没有响应

[BloodFighter]

如题，现在遇到一个诡异的问题，让我再次怀疑BCB的产品质量
问题描述：用BCB生成一个最简单的ocx，提供3个编辑框1个按钮
点击按钮，将前两个编辑框的数据求和，显示在第3个编辑框
死锁操作：将这个ocx放在一个vc的popup Dialog上，ok，程序运行正常
将这个ocx放在一个child dialog上，嵌入到刚才的popup dialog，alt_tab切换一下程序焦点，程序死循环了，没有了响应

一句话描述：BCB生成的ocx放在vc的子对话框上丢失焦点就崩溃，而放在vc的pop dialog就没有问题

通过spy++分析：陷入WM_GETLGCODE这个消息，一直死循环

这个问题必先，随便用bcb写一个ocx，放在vc的child dialog上就复现了，但是popup dialog就没有这个问题

C++ builder区也有100分，同一个问题，200分求解
http://topic.csdn.net/u/20100528/13/a475d502-4d9f-434c-8197-eda3480ef483.html?54699

[silentnight]

http://blogs.msdn.com/b/oldnewthing/archive/2004/07/30/201988.aspx
设置子对话框上设置WS_EX_CONTROLPARENT试试

[jameshooo]

我猜测是BCB的框架没有考虑这么复杂的应用情况，可能存在处理缺陷，导致父子对话框相互前转消息并最终死循环。

[King030609]

回帖拿10分，顺便帮顶下。

[visualassist4680]

[Quote=引用 1 楼 silentnight 的回复:]

http://blogs.msdn.com/b/oldnewthing/archive/2004/07/30/201988.aspx
设置子对话框上设置WS_EX_CONTROLPARENT试试
[/Quote]
cool

[BloodFighter]

这个方法是可以的，但是导致了其它的问题……

虽然这么不死了，但是我们的复杂bcb ocx会在别的地方崩溃……

如果没有修改这个对话框属性，至少我们的ocx还活着……

[BloodFighter]

我期望的解决方向是：处理好这个WM_GETLGCODE消息，在响应这个消息的时候，如何处理它，mfc的处理方法

而不是修改窗口属性，修改窗口属性虽然不在死循环，但是在别的应用揉在一起的时候，会导致其它问题

[BloodFighter]

自己顶一下，明后天结贴

[wencheng2998]

关注一下，现在还没涉及到这方面的问题~