GTk 抑制焦点移出
在我看来，验证用户输入的最佳位置是在条目类型小部件的焦点移出事件处理程序中（但这只是我的想法）。我尝试从焦点移出事件返回 TRUE，并认为这将避免将焦点转移到下一个控件并保持焦点在当前小部件上，但这不行（不能按需要工作）。
在验证未通过的情况下，哪种方法可以抑制将焦点转移到下一个控件，以及在何处将验证代码放在此类小部件（gtkEntry、gtkSpinButton 等）上，以便可与通过鼠标和键盘操作调用的信号一起使用？
It seems for me that best place for validation of user input is in focus-out-event handler of entry type widgets (but this is only my thinking). I try to return TRUE from focus-out-event with idea that this will avoid to transfer focus to next control and keep focus on current widget, but this is not OK (not work as needed).
Which is proper way to suppress of transfering focus to next control in case when validation don't pass and where to put validation code on such widgets (gtkEntry, gtkSpinButton, etc) to be usable with signals invoked with both - mouse and keyboard actions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这不是一个好主意......焦点（应该）始终由用户拥有。也就是说，用户应该能够将焦点移动到他们认为合适的地方。如果你试图根据你能想象到的任何逻辑来引导焦点或阻止焦点移动，你可能会让他们感到沮丧。
肯定会让我很沮丧！比如说，我在一个框中写了一个错误的数据，然后我说，“嘿，那是错误的！我想选择那边的数据，复制它并粘贴到这里”。但我不能这样做，因为程序不会让我在不写入可接受的数据的情况下离开我现在所在的盒子。我必须删除错误的数据并输入一些内容......只是不好。
验证用户输入的最佳方法是当您实际使用它执行某些操作时。无论是在保存时还是在使其生效时。然后你甚至可以制作一个弹出窗口，说有错误，当它关闭时，将焦点移动到第一个错误。
如果您认为用户可以从错误的早期警告中受益，您可以使用颜色（如果存在错误，则将框涂成黄色/红色），或者在框旁边添加一个小错误图标。这比转移焦点的破坏性要小得多。
That is hardly a good idea... Focus is (should be) always owned by the user. That is, the users should be able to move the focus wherever they see fit. If you try to direct the focus, or prevent moving it, based on any logic you can imagine, you will likely frustrate them.
It will surely frustrate me! Say for example that I wrote a wrong data in a box, and then I say, "hey, that's wrong! I want to select that data over there, copy it and paste it here". But I cannot do that because the program will not let me leave the box where I am now without writing an acceptable data. I have to delete the wrong data and enter something... just not good.
The best way to validate the user entry is when you actually do something with it. Either when you save it or when you make it effective. Then you can even make a pop-up saying that there is an error, and when it is close, move the focus to the first error.
If you feel that the user can benefit from an early warning that he is doing wrong, you can use colors (paint the box yellow/red if there is an error), or add a small error icon next to the box. That is waaaay less disruptive than moving the focus around.