输出只读,输入可使用 wx.textctrl 编辑?
大家好,
我正在使用 wxpython 开发用于软件配置、启动和交互的 GUI。我想要在 GUI 中嵌入 CLI shell 窗口(如 pycrust)之类的东西来与长期运行的后台进程进行交互。我可以通过这个 shell 窗口提供输入并在此窗口上打印输出。我当前的代码运行得很好。但是存在编辑样式的问题,因为wx.TextCtrl只是一个可编辑的文本窗口。例如,我可以覆盖或删除任何以前的文本字符或在任何位置键入新的输入。这是不可取的。
如何使 wx.TextCtrl 像 shell 窗口一样,即使输出只读,同时保持输入可编辑?例如,
1)当输入新命令时,只有在提示后才开始定位。
2) 用户不能更改或替换任何先前的输出文本。 我想强制某些限制,以达到交互目的。
有没有办法解决诅咒提示?如果是这样,那么我的问题就解决了,因为用户将没有机会移动诅咒。
或者有没有办法将文本的某些部分(输出和提示)设置为只读?
或者另一个解决方案,感谢9000的回答,是我制作一个窗口网格(一个StaticTextCtrl或只读TextCtrl用于在上部窗口中输出;在左下区域提示“>>”;不可见边框的可编辑窗口或右下区域的输入对话框进行输入)。
有什么建议吗?还有更好的选择吗? 多谢!
HI, guys,
I am using wxpython to develop a GUI for software configuration, launching and interaction. I want something like a CLI shell window (like pycrust) embedded inside the GUI to interact with a long-term running background process. I could give the input via this shell window and print the output on this window. My current code works very well. But there is problem of editing style, because wx.TextCtrl is simply an editable text window. e.g., I could overwrite or remove any previous text characters or type new input at any location. This is not desirable.
How can I make the wx.TextCtrl like a shell window, i.e. make the output readonly, while keep input editable? e.g.,
1) when input new command, the position only starts after prompt.
2) The user cannot change or replace any previous output text.
I want to force certain restriction, for interaction purpose.
Is there a way to fix the curse prompt? If so, then my problem will be solved, because the user will have no chance to move the curse.
Or is there a way to set certain part of the text (the output and the prompt) readonly?
Or another solution, thanks to 9000's answer, is that I make a grid of windows (a StaticTextCtrl or readonly TextCtrl for output in the upper window; prompt ">>>" on the bottom left area; invisible-border editable window or entry dialog on the bottom right area for input).
any suggestions? Is there any better choice?
Thanks a lot!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您可以考虑使用某种输入缓冲区。
从 TextCtrl 捕获每个 wx.EVT_KEY_DOWN 事件。如果击键产生一个字符,则将其附加到缓冲区并让它通过。如果是退格键,则从缓冲区中删除最后一个字符并允许它,或者如果缓冲区中没有剩余字符,则不允许它。这将保护当前行上的命令提示符。
您还必须处理可能重新定位光标的每个键盘或鼠标事件。如果您不希望用户能够在当前行内移动光标或移至上一行,则必须检测并取消箭头键、home、end、向上翻页、向下翻页、鼠标单击,等等。完全锁定可能很困难。
防止击键的示例:
祝你好运!
You could consider using some kind of input buffer.
Capture each wx.EVT_KEY_DOWN event from the TextCtrl. If it's a keystroke that produces a character, append it to your buffer and let it go through. If it's a backspace, remove the last character from the buffer and allow it, or if there are no characters left in the buffer, don't allow it. This will protect your command prompt on the current line.
You would also have to address each keyboard or mouse event that could reposition the cursor. If you don't want the user to be able to move the cursor around within the current line or move to previous lines, you'll have to detect and cancel arrow keys, home, end, page up, page down, mouse clicks, etc. It could be tough to lock down completely.
Example for preventing keystrokes:
Good luck!
在我们的产品中,我们有一个由两个编辑窗口组成的控制台,由一条细线分隔。上面的窗口是输出窗口,它是只读的。下部窗口是可编辑的。一旦您在其中编写了命令并提交了它,该命令就会从下部窗口中删除,并与命令的输出一起转到上部窗口。
您可以单击上方的窗口,从中选择某些内容,向上滚动等等,而无需从视线中删除当前正在编辑的命令。然后,单击下部窗口或按任意键,控件将返回到下部窗口,您可以在其中继续编写下一个命令。
In our product we have a console made up of two edit windows, separated by a thin line. The upper window is the output window, it is read-only. The lower window is editable. Once you have written a command in it and submitted it, the command is removed from the lower window and goes to the upper window, along with command's output.
You can click the upper window, select something from it, scroll it up, etc, all without removing the command you're currently editing from sight. Then you click on the lower window or press any key, and the control returns to the lower window, where you continue to craft your next command.
只需在每次显示提示时跟踪提示的位置即可。拦截所有按键和释放,如果有任何原因导致提示之前的文本发生更改,则否决该事件。这并不难,只需要稍微注意细节并勤奋地捕获所有文本修改事件。
Just keep track of the location of the prompt each time you display it. Intercept all keypresses and releases, and if anything causes text before the prompt to change, veto that event. It's not that hard, it just takes a little attention to detail and some diligence to capture all text-modification events.