Hi Neil,
I have a problem with wx.StyledTextCtrl that I need a workaround for. On the Mac, whatever text is put in the clipboard, even if it was using newlines for line endings, ends up having carriage returns for line endings when pasted. It appears that whatever the native platform line endings are, that's what text gets once in the clipboard. I didn't really notice this on Windows because all my documents had CR/LF line endings, but on the Mac, my "Unix" files use LF instead of the default Mac style of CR. What I want is for the pasted text to use the same line endings as the document being edited, so I assume I'll have to change my current Paste handlers to grab the clipboard, then iterate over each line and insert the line manually with CmdKeyExecute(stc.STC_CMD_NEWLINE)?
def on_menuEditPaste_select(self, event):
widget = self.findFocus()
if hasattr(widget, 'editable') and widget.CanPaste():
widget.Paste()
Is there a better solution?
There is another problem which may actually be a bug. Apparently, the pasted text when pasted into another application is terminated by an extra character, I think ASCII x00 (NULL), which of course isn't visible, but if I just copy some text from wx.STC and paste it into another Mac app like Mail.app then the character is obviously there because it takes two backspaces to back over the last character. In addition, I was told that some mail readers choke on the null character, which is originally how I found out about the problem. This doesn't seem to occur on Windows, so this might be a Mac-specific problem. The character doesn't show up when pasting back into wx.STC, only when pasting into another Mac app.
What I want is for the pasted text to use the same
line endings as the document being edited,
The GTK+ version of Scintilla does this. The function is ConvertLineEnds
in scintilla/gtk/ScintillaGTK.cxx. It should really be moved up into the
platform independent code and made more widely available.
so I assume I'll have to
change my current Paste handlers to grab the clipboard, then iterate
over each line and insert the line manually with
CmdKeyExecute(stc.STC_CMD_NEWLINE)
def on_menuEditPaste_select(self, event):
widget = self.findFocus()
if hasattr(widget, 'editable') and widget.CanPaste():
widget.Paste()
Is there a better solution?
You could call ConvertEOLs on the document after each paste.
There is another problem which may actually be a bug. Apparently, the
pasted text when pasted into another application is terminated by an
extra character, I think ASCII x00 (NULL), which of course isn't
visible, but if I just copy some text from wx.STC and paste it into
another Mac app like Mail.app then the character is obviously there
because it takes two backspaces to back over the last character.
On Windows a NUL is expected to terminate the clipboard text. wxSTC may
need to rely on platform-specific knowledge to determine how to copy text. I
would expect that there would be knowledge of this in the wxWidgets
clipboard code.
What I want is for the pasted text to use the same
line endings as the document being edited,
The GTK+ version of Scintilla does this. The function is ConvertLineEnds
in scintilla/gtk/ScintillaGTK.cxx. It should really be moved up into the
platform independent code and made more widely available.
I can do the same thing on the wxString before it gets converted for insertion into the document.
There is another problem which may actually be a bug. Apparently, the
pasted text when pasted into another application is terminated by an
extra character, I think ASCII x00 (NULL), which of course isn't
visible, but if I just copy some text from wx.STC and paste it into
another Mac app like Mail.app then the character is obviously there
because it takes two backspaces to back over the last character.
On Windows a NUL is expected to terminate the clipboard text. wxSTC may
need to rely on platform-specific knowledge to determine how to copy text. I
would expect that there would be knowledge of this in the wxWidgets
clipboard code.
I've verified that wxSTC is only putting the right number of characters into wxString that is given to the wxTextDataObject, perhaps there is a bug in how it makes the text available to the clipboard...
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
> The GTK+ version of Scintilla does this. The function is
ConvertLineEnds
> in scintilla/gtk/ScintillaGTK.cxx. It should really be moved up into the
> platform independent code and made more widely available.
I can do the same thing on the wxString before it gets converted for
insertion into the document.
I have copied the conversion code into Document if you want to use this.
The change is in Scintilla CVS.
I've verified that wxSTC is only putting the right number of characters
into wxString that is given to the wxTextDataObject, perhaps there is a
bug in how it makes the text available to the clipboard...
The SelectionText class in Scintilla always contains a NUL at the end in
case it is needed and this is counted in len, so you should use len - 1 (or
strlen) when copying to a string type that does not need NUL termination.
The SelectionText class in Scintilla always contains a NUL at the end in
case it is needed and this is counted in len, so you should use len - 1 (or
strlen) when copying to a string type that does not need NUL termination.
Yep, I saw that.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!