Copy & Paste doesn't work again

[Gerhard W. Gruber]

The last version (CVS from about two weeks ago I guess) supported Copy & Paste
from Agent to Linux apps. This doesn't work anymore.

[Rein Klazes]

On Sun, 29 Jun 2003 12:02:31 +0200, you wrote:
> The last version (CVS from about two weeks ago I guess) supported Copy & Paste
> from Agent to Linux apps. This doesn't work anymore.

This has not worked here correctly, since 2.5 years ago the clipboard
code was rewritten for unicode.

Occasionally it seems to work again. Just restart Agent and then you
find that it is not.

Rein.

[Gerhard W. Gruber]

On Sun, 29 Jun 2003 18:26:07 +0200, Rein Klazes  wrote:
> Occasionally it seems to work again. Just restart Agent and then you
> find that it is not.

I know that it worked. I used it quite frequently. I only update yesterday,
but I din't do it regulrarly teh last weeks. Before that it worked fine.

[Rein Klazes]

On Sun, 29 Jun 2003 19:59:40 +0200, you wrote:
> On Sun, 29 Jun 2003 18:26:07 +0200, Rein Klazes  wrote:
> > Occasionally it seems to work again. Just restart Agent and then you
> > find that it is not.
>
> I know that it worked. I used it quite frequently. I only update yesterday,
> but I din't do it regulrarly teh last weeks. Before that it worked fine.

I did notice here that copying from X to Agent (the other direction) has
stopped working completely recently. I will try to find the commit that
did this.

Rein.

[Rein Klazes]

On Sun, 29 Jun 2003 20:30:08 +0200, you wrote:
> On Sun, 29 Jun 2003 19:59:40 +0200, you wrote:
> > On Sun, 29 Jun 2003 18:26:07 +0200, Rein Klazes  wrote:
> > > Occasionally it seems to work again. Just restart Agent and then you
> > > find that it is not.
> >
> > I know that it worked. I used it quite frequently. I only update yesterday,
> > but I din't do it regulrarly teh last weeks. Before that it worked fine.
>
> I did notice here that copying from X to Agent (the other direction) has
> stopped working completely recently. I will try to find the commit that
> did this.

This is the commit:

| Log message:
| 	Ulrich Czekalla 
| 	- use global atoms for the format ids
| 	- add timeout when calling XCheckTypedWindowEvent
| 	- fix broken IsClipboardFormatAvailable; it tried to do a trick with
| 	EnumClipboardFormats by making incorrect assumptions
| 	- in X11DRV_IsClipboardFormatAvailable do a quick exit if no one owns
| 	the selection
| 	- add 1 second *minimum* time lapse between XSelectionOwner calls
| 	- sync clipboard ownership between different wine processes
| 	- prevents apps from getting into wierd state where they thought they
| 	didn't own the selection but they did and as a result queried
| 	themselves for available selection data
| 
| Patch: http://cvs.winehq.com/patch.py?root=/home/winehq/opt/cvs-commit&id=8573

Causing in Agent several problems:

- copy&paste from Agent to 'X' doesn't work, occasionally I see some
rubbish characters;
- copy&paste from 'X' to Agent doesn't work at all;
- copy&paste within Agent does not always work. For instance I cannot
copy Ulrich's email address from the text editor to the To:list at all.
Copying within the editor or from the cc:list to the To:list is no
problem.

Ulrich,I have never had much luck fixing things related to the
clipboard. Do you have a suggestion how to find out what the problem is?

Rein.

[Ulrich Czekalla]

Sure, I'll take a look. I need to look at this anyway to solve problems
with klipper interactions. I probably won't get around to this for a
couple of days since I'm really busy with other bugs but it is high on
my priority list. If you could send me a trace log of Agent with
+relay,+clipboard that would really help me out.

Thanks,

/Ulrich

On Mon, 2003-06-30 at 10:39, Rein Klazes wrote:
> On Sun, 29 Jun 2003 20:30:08 +0200, you wrote:
> > On Sun, 29 Jun 2003 19:59:40 +0200, you wrote:
> > > On Sun, 29 Jun 2003 18:26:07 +0200, Rein Klazes  wrote:
> > > > Occasionally it seems to work again. Just restart Agent and then you
> > > > find that it is not.
> > >
> > > I know that it worked. I used it quite frequently. I only update yesterday,
> > > but I din't do it regulrarly teh last weeks. Before that it worked fine.
> >
> > I did notice here that copying from X to Agent (the other direction) has
> > stopped working completely recently. I will try to find the commit that
> > did this.
>
> This is the commit:
>
> | Log message:
> | 	Ulrich Czekalla 
> | 	- use global atoms for the format ids
> | 	- add timeout when calling XCheckTypedWindowEvent
> | 	- fix broken IsClipboardFormatAvailable; it tried to do a trick with
> | 	EnumClipboardFormats by making incorrect assumptions
> | 	- in X11DRV_IsClipboardFormatAvailable do a quick exit if no one owns
> | 	the selection
> | 	- add 1 second *minimum* time lapse between XSelectionOwner calls
> | 	- sync clipboard ownership between different wine processes
> | 	- prevents apps from getting into wierd state where they thought they
> | 	didn't own the selection but they did and as a result queried
> | 	themselves for available selection data
> | 
> | Patch: http://cvs.winehq.com/patch.py?root=/home/winehq/opt/cvs-commit&id=8573
>
> Causing in Agent several problems:
> - copy&paste from Agent to 'X' doesn't work, occasionally I see some
>
> rubbish characters;
> - copy&paste from 'X' to Agent doesn't work at all;
> - copy&paste within Agent does not always work. For instance I cannot
>
> copy Ulrich's email address from the text editor to the To:list at all.
> Copying within the editor or from the cc:list to the To:list is no
> problem.
>
> Ulrich,I have never had much luck fixing things related to the
> clipboard. Do you have a suggestion how to find out what the problem is?
>
> Rein.

[Ferenc Wagner]

Ulrich Czekalla  writes:
> Sure, I'll take a look.

Once at it, let me express my concerns.  Before that last
patch went in, I was using the following local
modifications:

Index: dlls/x11drv/clipboard.c
===================================================================
RCS file: /home/wine/wine/dlls/x11drv/clipboard.c,v
retrieving revision 1.8
diff -u -r1.8 clipboard.c
--- dlls/x11drv/clipboard.c     23 Jan 2003 21:32:35 -0000      1.8
+++ dlls/x11drv/clipboard.c     25 Mar 2003 15:36:52 -0000
@@ -165,10 +165,6 @@
         case CF_TEXT:
            return None;

-        case CF_UNICODETEXT:
-            prop = XA_STRING;
-            break;
-
         case CF_DIB:
         case CF_BITMAP:
         {

I wanted to move Unicode text between Windows applications,
but the above rule always converted it to iso-8859-1,
destroying the contents.  As far as I remember, there was no
mechanism to offer (for a TARGET request) several possible
transfer formats, raw internal being the preference,
followed by other less convenient formats.

@@ -947,6 +943,16 @@
     if ( !(selectionAcquired == (S_PRIMARY | S_CLIPBOARD)) )
     {
         Atom xaClipboard = TSXInternAtom(display, _CLIPBOARD, False);
+        BOOL TempWndCreated = False;
+
+        if (hWndClipWindow == NULL)
+        {
+            hWndClipWindow = CreateWindowA ("STATIC", NULL, 0,
+                                            0, 0, 0, 0,
+                                            NULL, NULL, NULL, NULL);
+            TempWndCreated = True;
+          }
+
         owner = X11DRV_get_whole_window( GetAncestor( hWndClipWindow, GA_ROOT )
 );

/* Grab PRIMARY selection if not owned */
@@ -968,6 +974,9 @@
            selectionWindow = owner;
            TRACE("Grabbed X selection, owner=(%08x)\n", (unsigned) owner);
         }
+
+        if (TempWndCreated)
+            DestroyWindow (hWndClipWindow);
     }
 }

X11DRV_AcquireClipboard can be called with NULL
hWndClipWindow (as documented on MSDN).  The above hack came
over it without introducing new global state, but clearly is
not right.  Worked for me, though.

I wanted to investigate and find real fixes for both
problems, but after your recent patches I will have to learn
the new ways first.  And I do not really have the time
anyway, so I thought I had better tell about them at least.

Feri.

[Ulrich Czekalla]

On Wed, 2003-07-02 at 07:34, Ferenc Wagner wrote:
> Ulrich Czekalla  writes:
> > Sure, I'll take a look.
>
> Once at it, let me express my concerns.  Before that last
> patch went in, I was using the following local
> modifications:
> Index: dlls/x11drv/clipboard.c
>
> RCS file: /home/wine/wine/dlls/x11drv/clipboard.c,v
> retrieving revision 1.8
> diff -u -r1.8 clipboard.c
> --- dlls/x11drv/clipboard.c     23 Jan 2003 21:32:35 -0000      1.8
> +++ dlls/x11drv/clipboard.c     25 Mar 2003 15:36:52 -0000
> @@ -165,10 +165,6 @@
>          case CF_TEXT:
>             return None;
> -
>    case CF_UNICODETEXT:
> -
>        prop = XA_STRING;
> -
>        break;
> -
>    case CF_DIB:
>    case CF_BITMAP:
>    {
>
> I wanted to move Unicode text between Windows applications,
> but the above rule always converted it to iso-8859-1,
> destroying the contents.  As far as I remember, there was no
> mechanism to offer (for a TARGET request) several possible
> transfer formats, raw internal being the preference,
> followed by other less convenient formats.

Good point. I'll fix this.
> @@ -947,6 +943,16 @@
>      if ( !(selectionAcquired == (S_PRIMARY | S_CLIPBOARD)) )
>      {
>          Atom xaClipboard = TSXInternAtom(display, _CLIPBOARD, False);
> -
>    BOOL TempWndCreated = False;
> -
> -
>    if (hWndClipWindow == NULL)
> -
>    {
> -
>        hWndClipWindow = CreateWindowA ("STATIC", NULL, 0,
> -
>                                        0, 0, 0, 0,
> -
>                                        NULL, NULL, NULL, NULL);
> -
>        TempWndCreated = True;
> -
>      }
> -
>    owner = X11DRV_get_whole_window( GetAncestor( hWndClipWindow, GA_ROOT )
>
> );
>      /* Grab PRIMARY selection if not owned */
>
> @@ -968,6 +974,9 @@
>             selectionWindow = owner;
>             TRACE("Grabbed X selection, owner=(%08x)\n", (unsigned) owner);
>          }
> -
> -
>    if (TempWndCreated)
> -
>        DestroyWindow (hWndClipWindow);
> }
>
> }
>
> X11DRV_AcquireClipboard can be called with NULL
> hWndClipWindow (as documented on MSDN).  The above hack came
> over it without introducing new global state, but clearly is
> not right.  Worked for me, though.

Yes I noticed this as well. What we do in other areas is use
GetActiveWindow() if hWndClipWindow == 0. I have something like this in
my tree. I'll submit a patch soon.
> I wanted to investigate and find real fixes for both
> problems, but after your recent patches I will have to learn
> the new ways first.  And I do not really have the time
> anyway, so I thought I had better tell about them at least.

Sure, any feedback help a lot. Thanks!
>                                       Feri.

[Ferenc Wagner]

Ulrich Czekalla  writes:
> > X11DRV_AcquireClipboard can be called with NULL
> > hWndClipWindow (as documented on MSDN).  The above hack
> > came over it without introducing new global state, but
> > clearly is not right.  Worked for me, though.
>
> Yes I noticed this as well. What we do in other areas is
> use GetActiveWindow() if hWndClipWindow == 0. I have
> something like this in my tree. I'll submit a patch soon.

Although being much simpler, it probably has the same
problem, I am afraid.  MSDN:

If an application calls OpenClipboard with hwnd set to
    NULL, EmptyClipboard sets the clipboard owner to NULL;
    this causes SetClipboardData to fail.

But my application does not depend on this (and I am not
sure I understand who would), so the fix would help.

Thanks a lot,
Feri.