On Thu, 17 Dec 2009, Przemysław Czerpak wrote: hi,
> > I've just checked and same OS X GTXWC app picked what was > > placed to clipboard before starting the app (or even > > starting X11 for that matter). > > I'll keep an open eye to report any clipboard problems > > here. > > Please try it after: > 2009-12-17 03:45 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) it is better now, in the sense that now the primary is retained and can be reliably read by hb, but a small artifact remains. i am using a test along the lines of: #include "inkey.ch" #include "hbgtinfo.ch" FUNCTION MAIN() REQUEST HB_GT_XWC, HB_GT_CRS, HB_GT_TRM hb_gtInfo( HB_GTI_CLOSABLE, .F. ) hb_gtInfo( HB_GTI_WINTITLE, "X Clipboard/PrimarySelection test" ) hb_gtInfo( HB_GTI_SELECTCOPY, .T. ) hb_gtInfo( HB_GTI_RESIZABLE, .F. ) @ 1, 1 SAY "Copy in something (key)" InKey(0) @ 2, 1 SAY "Clipboard data:" alert( hb_gtInfo( HB_GTI_CLIPBOARDDATA ) ) @ 3, 1 SAY "Copying in 'erglebergle' (key)" hb_gtInfo( HB_GTI_CLIPBOARDDATA, "erglebergle" ) InKey(0) @ 4, 1 SAY "Paste primary (key)" InKey(0) @ 5, 1 SAY "Paste clipboard (key)" InKey(0) @ 6, 1 SAY "In clipboard:" alert( HB_GTINFO( HB_GTI_CLIPBOARDDATA ) ) @ 8, 1 SAY "Exit (key)" InKey(0) RETURN NIL (that is, you are supposed to do what it says by copying from and pasting into other clients when the test app says so) the symptom is that when there is already data in the primary when this app is started, the first inkey(0) is immediately satisfied (and then it shows the correct content for the primary selection). this doesn't happen absolutely always, but it does most of the time. if the primary is empty at app startup, then it never happens. another artifact is that upon exit (i start it from an xterm), it leaves some garbage someplace, which which causes my xterm to disappear if i press middle button. it's nothing that i could catch with careful use of xxd waiting for some binary junk, what's more, at one occasion this even killed my windowmaker (ok, it's not the stablest wm in the world, but for a couple of month, since outstandings have been fixed, i've been having much less problems with it than i used to). even worse, this doesn't seem to be tied to middle button events. i have had it by middle button, up arrow in shell, ^C in a shell line i decided not to execute... so the guess it that *something* is there that causes clients to exit unexpectedly. it is not even sure that the client that exits is the one that has the focus (i was just at this moment playing with other xterms when this one that runs my mua decided it's been long since i last saw my desktop background...) -- [-] mkdir /nonexistent _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
