仅仅Windows文本框今天让我大吃一惊。
我在应用程序中有两个不相关的文本框。我可以输入任一文本框并通过单击它们来切换焦点。然后发生了一些事件X，由于下面给出的原因，我无法在此描述。在这个事件发生之后，两个文本框以几乎量子的方式变得“纠结”。
比如说，文字框A在X发生之前就被聚焦了。当我单击文本框B键入某些文本时，新文本显示在文本框A中，而闪烁的光标在文本框B中通过空格愉快地移动，就好像文本在那里一样。
点击任意一个文本框都无法解决此问题。光标将始终保留在B中，而文本将始终显示为A.
消息间谍揭示了在事件X之后，文本框失去了丢失或获得焦点的能力。当我点击B时，WM_LOSE_FOCUS没有来到A，WM_SET_FOCUS没有来到B.（方框的矩形和可见性都没问题。）
在Windows XP和Windows 7中也会发生同样的事情。
现在，事件X：这是第三方UI库中的一件大事，我无法及时进行逆向工程。 （即，将窗格停靠在wxAUI中。）
我确信这种行为是对文本框的不正确WinAPI调用（垃圾进入 - 垃圾输出）的结果。我想知道什么可能导致这样的“文本框之旅”知道从哪里开始寻找bug。
谢谢！
答案 0 :(得分：3)
我发现了问题。那是我。焦点管理中存在一个愚蠢的错误。它使焦点快速（立即）转移到文本框B，然后在“事件X”之后立即返回到文本框A.虽然它只发生过一次，但它足以在文本框中造成严重破坏，直到他们的生命结束。
为什么特效？事实证明，Windows讨厌使用UI元素进行两次快速连续操作。当我试图通过在两个不同的步骤中设置其原点和大小来移动控件时，我曾经有过类似的奇怪错误。在此之后，控件将表现得非常随机。只有当我正确地移动它 - 一步 - 怪异才停止。
感谢您的关注和抱歉打扰。
答案 1 :(得分：1)
这是一个非常奇怪的问题，如果不能查看某些代码，我能做的最好的就是一个有根据的猜测。
听起来像UI库正在处理文本框B的通知（按键，焦点等）并对它们进行操作，就好像它们是用于文本框A一样。就像有一个像{{1}这样的变量保存文本框A的句柄，即使它应该指向文本框B。
虽然我可以想象导致这种行为的UI库错误，但我认为客户端代码更有可能导致它。您是否排除了代码作为罪魁祸首？
答案 2 :(得分：0)
文本框是否有唯一标识符？
您是否正确绑定了他们的消息和消息处理程序？
特别是，它听起来像具有事件X的控件可能具有与控件标识符冲突的子控件标识符。
如果问题是可重现的，那么我会做一个小的测试示例并将其发送给控件的供应商。