Problem with Key Events in wxRichTextCtrl on OS X with wxPython 3.0.2.0

[David Woods]

Hi all, and especially Robin,

Sorry I can't explain this any better than I do, but I thought it would
be best if I at least reported what I'm seeing.

I've been working on a very complex application using Python and
wxPython for many years and through many wxPython versions. It relies
on a custom editor derived from wxRichTextCtrl as a central control for
transcribing and doing qualitative analysis with video and audio data.

In preparation for my next release, I upgraded to wxPython 3.0.2.0 with
Python 2.7.8. I'm doing my final pre-release testing, and I noticed
that when I type as fast as I'm capable of, characters were getting
dropped on OS X. (This problem does not occur on Windows, but I still
use wxPython 3.0.1.1 on Windows which may be why. FYI, I use the
carbon build, not the cocoa build on OS X.)

I have a lot of code in EVT_KEY_DOWN, EVT_CHAR, and EVT_KEY_UP handlers
by necessity, and at first, I thought this was the source of my
difficulties. I determined that when keys started building up in the
keyboard buffer, my EVT_KEY_DOWN and EVT_CHAR handlers just weren't
getting called for some characters, though the EVT_CHAR_UP handler was
always getting called. (I can create the problem about 1/2 the time by
typing the word "the", a word I can type really fast. The "e" does not
always get processed.) I've noticed that it's the event.Skip() call in
my EVT_CHAR handler that actually causes the character being processed
to appear on the screen, so the failure of the EVT_CHAR handler call
explains the symptom of missing characters.

I eliminated the bindings for these three event handlers in my control,
so my code wasn't getting called at all, but the symptom of missed
characters persisted, which makes me think it's not my event handler
code that's the core of the problem.

I then removed wxPython 3.0.2.0 from my system, and installed 3.0.1.1
instead. (I also restored my event handlers.) And the symptom of
missing characters is not evident; all event handlers are getting
called. That makes me think something happened between 3.0.1.1 and 3.0.2.0.

I should note that when I start my app with 3.0.2.0, I reliably get a
Terminal message that states:

2015-04-21 13:44:18.775 Python[750:f07] CFURLCreateWithString was passed
this invalid URL string:
'/System/Library/CoreServices/CommonCocoaPanels.bundle' (a file system
path instead of an URL string). The URL created will not work with most
file URL functions. CFURLCreateWithFileSystemPath or
CFURLCreateWithFileSystemPathRelativeToBase should be used instead.

I don't get that message with 3.0.1.1. To be honest, I'm not sure what
it means or if it's related.

Finally, I tried to create a "simple" example but was unable to get the
problem to occur, so I may not be completely innocent here. I'm not
sure what of my code would be getting called on key events when I've
disabled by key event handlers. It's possible the issue is related to
the complexity of data files, as I discovered the problem when testing
with extremely long documents and with documents with embedded images,
or that there's interference with an EVT_IDLE handler somewhere.

Let me know if you have questions.

David

--
David K. Woods, Ph.D.
Researcher, Transana Lead Developer
Wisconsin Center for Education Research
University of Wisconsin, Madison
http://www.transana.org

[David Woods]

I have spent more time on this issue in the past few days. I won't say
I've made progress, but I have discovered a few things.

I'd said the problem didn't occur on Windows, but realized I hadn't
actually tested 3.0.2.0 on Windows, so I checked that. The problem is
limited to wxPython 3.0.2.0 on OS X, and does not occur with wxPython
3.0.2.0 on Windows or with wxPython 3.0.1.1 on either platform.

It appears that the issue doesn't occur in an otherwise empty document.
I seem to have problems only when editing transcripts with some degree
of formatting complexity, that is with numerous font and paragraph
formatting changes.

The length of the document does not appear to matter. I can make it
reliably occur in a document that's only 75 paragraphs long, but not in
a longer document with no formatting changes.

I had an issue with typing speed in long RichTextCtrl documents back in
February, 2014, for which Julian recommended
RichTextCtrl.SetFloatingLayoutMode(False) as a fix and which Robin
enabled. I double-checked that the current issue is NOT related to that
issue, in that removing that line of code didn't make things any better
(but re-enabled the original typing speed issue.)

David