On Fri, 02 Apr 2021 10:08:20 +0200, Marc Weustink via lazarus
wrote:
>Just s general warning, it doesn't say anything about your observations.
>
>Be careful with drawing conclusions when using vnc. The past year I've been
>working remote and I'm using vnc to access my desktop at work.
Just s general warning, it doesn't say anything about your observations.
Be careful with drawing conclusions when using vnc. The past year I've been
working remote and I'm using vnc to access my desktop at work. Transferring
clipboard data most times work, but sometimes it is a pain. It won't
On Thu, 1 Apr 2021 03:26:47 -0400, Anthony Walter via lazarus
wrote:
>I noticed a recent discussion touching on this problem posted by Bo
>Berglund on November 20, 2020 to this same mailing list.
>
I'm back...
In fact I have a *related* clipboard issue inside Lazarus itself:
Working in Lazarus
Colin,
After some research I've found that LCL Gtk2 isn't using gtk_clipboard_x
functions, rather it's using gtk_selection_x functions. There are
gtk_clipboard functions to do the same thing as gtk_selection functions,
but because the gtk_clipboard functions are not being used, the
(You have definitely educated me)
I tried something similar on one of my own applications, and it doesn't
work for me either. I suspect sometihing more elaborate is required, as
I don't think the LCL does calls gtk_clipboard_set_text, even for text.
Reading the documentation for
Here is a follow-up.
I wrote a simple test using LCL Gtk2 and gtk_clipboard_store. This test
allows the clipboard data to persist after my program exited. Button1 click
sets the clipboard data. If Button2 clicked the data will persist after the
program exits. If Button2 is not clicked, the data
Thanks Michael.
It looks as if this problem was fixed in Gtk2 by version 2.6. The
developers added this function to work around this problem:
void gtk_clipboard_store (GtkClipboard *clipboard);
Stores the current clipboard data somewhere so that it will stay around
after the application has
On Thu, 1 Apr 2021, Anthony Walter via lazarus wrote:
Perhaps there is a Linux service that can be used by applications to hand
over and take ownership of clipboard data, and applications such as those I
mentioned are using it in order to solve the problem I am describing?
See my earlier
Perhaps there is a Linux service that can be used by applications to hand
over and take ownership of clipboard data, and applications such as those I
mentioned are using it in order to solve the problem I am describing?
--
___
lazarus mailing list
On Thu, 1 Apr 2021, Anthony Walter via lazarus wrote:
I noticed a recent discussion touching on this problem posted by Bo
Berglund on November 20, 2020 to this same mailing list.
Andreas Schneider replied in that thread, 'Pasting basically asks the
application that "copied" it to get the
I am very confident that the X11 behaviour is that the data goes with the
application. It might be that more recent desktops/toolkits have some work
around, but the gtk2 functions lazarus uses only copy data externally when
asked for by an X11 messaage and this is all gtk2 provides.
Colin
>
I noticed a recent discussion touching on this problem posted by Bo
Berglund on November 20, 2020 to this same mailing list.
Andreas Schneider replied in that thread, 'Pasting basically asks the
application that "copied" it to get the content. If that app is gone in the
meantime, there's nothing
This is the way the linux clipboard works - the data is kept with the source
program, so goes when the program closes.
Colin
> On 01/04/2021 07:58 Anthony Walter via lazarus
> wrote:
>
>
> On Linux Gtk2, over time I have noticed a problem where data copied to the
> clipboard by a Lazarus
13 matches
Mail list logo
