;) Okay, this is pretty far-fetched and esoteric, but it really did happen to me so I might as well post a bug. I wont feel hurt if you wontfix this bug and in fact, it might even be a bug in wxPython or wxWindgets.
Anyway (blush) it boils down to this. It would seem the Windows clipboard can be locked or busy with another operation. I was able to do this by copying an image in Paint Shop Pro and then "Pasting As Selection" to data into another image, but not completing the paste. I then switched back to DrPython and did a cut (for a paste) on some text.
The text disappeared and an error box popped up with:
Failed to put data on the clipboard (error -2147221040: openClipboard Failed)
I admit, this is an ultra-rare occurence, but I think the proper way to handle this event is to check the return code of the "cut" call and if it's not successfull, don't clear the text.
Logged In: YES
user_id=796750
Yowza.
I checked the wxStyledTextControl documentation, and at
first glance there does not seem to be a way to do this.
Its times like these I REALLY like linux :). Gimp gives me
no problems (and you can get the gimp for windows).
Back to your submitted bug, who knows?
This could be a memory leak in DrPython, in wxPython, in
python, in Paint Shop Pro, or Windows.
It could be a clipboard error with any of the same.
Does the same thing happen if you replicate this with
another paint program? How about another text program?
Another wxPython program?
And how on earth did you come across this bug?
I will look into this, this bug seems to have bothered other
open source programs on windows, including evolution(a mail
client) and idle.
Logged In: YES
user_id=53053
Hehe... It looks to me like the windows api is throwing a "sorry buddy clipboard's locked" exception.
Interestingly, MS's flagship product MS-Word also fails to handle this situation. It looks like the exception is silently caught and dropped. However, Wordpad handles the situation more correctly. In Wordpad, the text is not cleared and no error is given. Attempting to paste the text that wasn't cut results in a generic error tone.
I suspect seeing this in DrPython is just a result of an unchecked exception bubbling from the win api and up through wxWindgets.
How did I find this? I'm working on a PyGame program and I have a couple sprites. I was using PSP's paste as selection function to temporarily position a sprite against the background image. I found if I never tell it okay put it here, I can keep moving it and reading it's position. Then I went to code the positions into my python script.
Oh, and I like Linux too. :) I only lack a HD and processor for me gentoo box to be.
Logged In: YES
user_id=796750
Well, this does seem esoteric, but more importantly, there
does not seem to be a way to handle it that is not a bother
to everyone else who never run into this bug.
I would have to manually override EVERY paste operation,
and give it a shot, if it doesn't work, abort early without
messing with the text.
I don't have a way of duplicating this, so if you can figure
out how to duplicate it, and find a way to catch the error,
then I can find a way to code it in as an option:
Under General Prefs:
Use "Safe" Paste,
and note that this is only useful on windows, in the
situation you describe.
Other than that, there does not seem to be anything to do here.
Logged In: YES
user_id=53053
Dan,
I personally recommend resolving this as wontfix. I dug into it a little out of curiousity. It looks like the CmdKeyExecute returns void so there's no checking a return value. Whatever performs the cut operation should check for success before it clears the text. I suspect this is in the wxSTC or more likely the underlying scintilla code. Either way, it's their responsibility and not DrPythons. So maybe invalid is the most appropriate resolution.
Logged In: YES
user_id=796750
I am reluctant to do so, but sounds right to me. If you
check in the Drpython code, there are some work arounds for
underlying bugs in scintilla and wxpython. The problem here
is that any fix will likely add overhead that will not be
needed for 99% of users 99% of the time. On top of this,
the bug can be overridden by simply using "undo" whenever it
occurs.
So this bug is officially closed.
Thank you for your time and effort, in particular for your
detective work.