xwinclip test 6 hacked to leave selection untouched

[Harold L Hunt II]

Robert,

First, this might be really cool.  I had code in xwinclip a long time 
ago that watched the Windows clipboard and did almost exactly the same 
thing that you have done... except that our processing of Windows 
messages was not yet correct so xwinclip ended up hanging when its 
message queue overflowed.  Now that the message processing is fixed this 
new patch should work well.

I won't have a chance to test this until tonight or later.

One side note though... please do not call your xwinclip releases test7, 
or test8, etc. as this will create a great amount of confusion when 
trying to determine if a user has a problem with an official release or 
an independent developer's release.  Call them something like 
xwincip-robf1.tgz.

Thanks for the patch,

Harold

Robert Fenk wrote:

>Hi,
>
>I found it quite annoying that xwinclip-test6 was grabbing
>the ownership of the selection every-time it looses it while
>IMHO it should just grab it when there is a new selection in
>the MS-Windows clipboard.  Grabbing means the original
>application is loosing it and with xterm and xemacs it means
>that the selection is really lost, dehighlighted and not
>available anymore.
>
>So I did some googling how to detect clipboard changes on
>MS-Windows and added the code for this to wndproc.c and
>modified xevents.c to just grab the selection if a
>MS-Windows clipboard change is detected which is not caused
>by xwinclip itself (this part is really a hack).  
>
>The code might be helpful for those working on improved xwinclip
>versions, but I do not have any intention on more hacking.
>I actually have no idea about MS-Windows API and X11 so
>there are probably new bugs ...
>
>http://www.robf.de/Hacking/xwinclip-test7.tgz
>
>Bye Robert
>
>PS: I have not subscribed to this list so you should address
>    questions with a CC to me.
>
>  
>