This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: XFree86-xserv-4.3.0-35
- From: Harold L Hunt II <huntharo at msu dot edu>
- To: cygwin-xfree at cygwin dot com
- Date: Sat, 10 Jan 2004 22:34:21 -0500
- Subject: Re: XFree86-xserv-4.3.0-35
- References: <4000A731.1070904@msu.edu> <4000BFAC.8030905@gmx.de>
- Reply-to: cygwin-xfree at cygwin dot com
Holger,
Holger Krull wrote:
Hello,
the previous problem is gone, now large amount of text can be
transfered. Really great.
I wasn't able to duplicate that particular bug anyhow... so it is good
that it is not happening for you anymore :)
A small qirk is left, if i copy a graphic in Windows and try to paste it
X11 OpenOffice it get the message that the desired format isn't
available in the clipboard (no surprise here).
Hmm... that is because I need to release ownership of the X11 selections
(if the clipboard client currently owns the selections) the first time
that some unsupported format is copied to the Win32 clipboard. That way
no X Client will request the clipboard contents from us when the Win32
clipboard does not contain text.
I missed that one when I decided what fixes need to be made. I guess I
will have to fix this now too :) It will be tough to get it right
though, because the current code has a lot of special values used to
make sure that two functions don't get in an infinite loop of disowning
and re-owning selections and the clipboard. I have to be very careful
to make sure that any side-effects from further changes do not cause
infinite loops.
But after that the Windows clipboard is blocked (no copy, no paste, only
error messages) until i put something in the X11 clipboard. Maybe this
the same problem you didn't want to be mentioned until someone found a
solution.
Nope, what you describe is different than what I said not to complain
about. What was happening here is that I called OpenClipboard, then
checked IsClipboardFormatAvailable and aborted without calling
CloseClipboard if the desired format was not available. That left the
Win32 clipboard locked and prevented other apps from changing it. Our
app could call OpenClipboard though, so that is why selecting something
in X11 fixed the problem. This problem should not happen when the above
fix is implemented, but I think it is really worth fixing this right now
since it is so simple and will prevent really bad behavior. So, I am
posting 4.3.0-36 right now.
Harold