I have noticed this problem with wx.stc widgets on my system recently. After I use an "editing" key (backspace, delete, insert, tab, any of the arrow keys) I am unable to insert any "printable" character into the Stc text widget, unless I type a Ctrl+C or Ctrl+H or Ctrl+some key combination. I can, however, use the editing keys multiple times - so I can delete many characters, or insert multiple tabs, or any combination of editing keys and get the expected result. It is just that once I've used any of these keys further text input requires typing a Ctrl+(A|C|H|..) key.
While I stumbled on this problem when using the Editra text editor, I find that the problem is observable while using the StyledTextCtrl_1.py demo as well as with the StyleEditor tool in the samples directory.
I have also compiled wxPython-2.8.12.1 from source and confirmed that the curious behaviour persists. I have this feeling that I am missing something elementary here, so any pointers will be gladly appreciated.
I have noticed this problem with wx.stc widgets on my system recently.
After I use an "editing" key (backspace, delete, insert, tab, any of the
arrow keys) I am unable to insert any "printable" character into the Stc
text widget, unless I type a Ctrl+C or Ctrl+H or Ctrl+some key combination.
I can, however, use the editing keys multiple times - so I can delete many
characters, or insert multiple tabs, or any combination of editing keys and
get the expected result. It is just that once I've used any of these keys
further text input requires typing a Ctrl+(A|C|H|..) key.
While I stumbled on this problem when using the Editra text editor, I find
that the problem is observable while using the StyledTextCtrl_1.py demo as
well as with the StyleEditor tool in the samples directory.
I have also compiled wxPython-2.8.12.1 from source and confirmed that the
curious behaviour persists. I have this feeling that I am missing something
elementary here, so any pointers will be gladly appreciated.
Not sure if it is 100% related but there are some issues with how the
control processes certain key codes with some keyboards. I found a
potential solution for the issue reported at
(wxTrac has been migrated to GitHub Issues - wxWidgets) but requires a patch to be
applied to the c++ source code. Could you try applying the
patch/rebuilding to see if it also corrects this issue or not?
Robin do you have any comment on the patch I attached to the above
tracker ticket?
Regards,
Cody
···
On Tue, Nov 22, 2011 at 9:22 AM, Raj <rajgopal.srinivasan@gmail.com> wrote:
Thanks for the reply. I tried applying the patch and that did not fix things. I am going through the code and let me see if I can work out the logic. Interestingly, just pressing and releasing the ctrl, alt or shift keys is enough to re-enable text entry. What this means is that in wxStyledTextCtrl::OnKeyDown, the processed variable will be non-zero and therefore evt.Skip() will not be called. This may provide a clue to solving my issue. I’ll get some time later in the day to look at this. Thanks for the suggestion.