在对话框中以编程方式更改 Tab 键顺序的其他方法
我试图找出为什么在使用 Tab 键导航时，Windows 对话框中的一些动态创建的子控件出现乱序。在没有任何其他东西摆弄它们的情况下，顺序应该按照它们添加到对话框中的顺序来定义，但一种特定类型的子控件始终排在最后。
我知道一种方法 要对它们重新排序，请使用 SetWindowPos()，使用 hWndInsertAfter 参数，而不设置 SWP_NOZORDER 标志。我相当确定我已经排除了此重新排序的可能原因。
因此，为了进一步了解这一点并仅供将来参考，除了 SetWindowPos() 之外，还有哪些其他 win32 调用可以对对话框中的现有子控件重新排序？
I'm trying to track down why some of my dynamically created child controls in a Windows dialog are out of order when it comes to navigating them with the tab key. In the absence of anything else fiddling with them, the order should be defined by the order in which they are added into the dialog, but one specific type of child control is consistently being sorted last.
I know that one way to re-order them is using SetWindowPos(), using the hWndInsertAfter parameter and without setting the SWP_NOZORDER flag. I am fairly sure I've eliminated this as the possible cause of this re-ordering.
So, for further leads into this as well as just for future reference, apart from SetWindowPos(), what other win32 calls can re-order existing child controls in a dialog?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
差不多就是这样 - 在标准对话框中，Tab 顺序就是 z 顺序，只不过您可以控制从 z 顺序开始的位置。如果您有几个控件始终位于 Tab 键顺序的末尾，则说明某些东西正在操纵 z 顺序以将它们放在那里。
如果对话框或控件是非标准的，则 Tab 键顺序可以直接由 WndProc 操作。这通常是一个坏主意，但已知时常发生。
That's pretty much it - in a standard dialog, the tab order is just the z order, except that you can control where to start in the z order. If you've got a couple of controls that always end up at the end of your tab order, something is manipulating the z order to put them there.
If the dialog or controls are non-standard, the tab order may be manipulated directly by the WndProc. This is generally a bad idea, but has been known to happen from time to time.