I am running Lazarus on a Linux system (Raspbian Jessie) but that system is headless so I use TightVNC to get a desktop on my Win7 PC. It works pretty well except for the clipboard that is supposed to be shared between the two systems.
The .vnc/xstartup file in the home directory on Raspbian has been edited to include the line:
autocutsel -fork
as described in several places on the net for clipboard sharing across VNC sessions.

What actually happens is this:
1) Copy text on the Windows side
Go to the Lazarus editor in the VNC window and paste (Ctrl-V) - it works just fine and the text appears in the Lazarus editor.

2) Copy some part of code in Lazarus code editor either by selecting it and hitting Ctrl-C or by right-clicking the selection and use the Copy function.
Back in the Windows text editor Ctrl-V now pastes the text I *previously* copied in Windows and pasted in Lazarus...

3) In VNC open the Raspbian text editor and do a Ctrl-V in that. The text copied in Lazarus is now written to the edit window.

4) Now move back to Windows text editor and paste with Ctrl-V. Result:
The text from Lazarus that was pasted into the Raspbian editor is now also pasted in Windows.

So it seems like the action to paste the text copied in lazarus code editor into another application inside Linux makes it available on the Windows side too...

To me this looks like Lazarus is doing something strange when one uses Copy inside the code editor (and in fact also in the messages window) so that the pasting is only working inside Linux, but once it has been pasted in Linux but outside Lazarus it is properly set in the Linux clipboard and then also available for Windows.
It does not help to paste the text in the Lazarus code editor, it still won't paste in Windows.

Is this a known issue with the Lazarus handling of the clipboard? Or is there a configuration item in Lazarus that may modify this?

Using Lazarus 1.5 SVN 50059 with FPC 3.1.1

Bo Berglund wrote

except for the clipboard that is supposed to be shared between the two systems.

This rather obviously is is not an FPC or Lazarus problem but introduced by Tight VNC and hence should be discussed elsewhere. Maybe a greater VNC Version would work better.

-Michael

No, as I've said before there are general problems in both VNC implementations and these predate the real/tight split.

If you want to do significant amounts of cut-and-paste then run Lazarus over SSH (i.e. so that the Lazarus UI is being presented by the local X server). If that introduces a significant performance hit then report it as a bug, it's something that's crept into a small number of Lazarus versions and is usually fixable.

Mark Morgan Lloyd wrote

No, as I've said before...

Seemingly this mail is not in the List.

-Michael

Do you mean Start Lazarus from the command line via SSH after setting the "DISPLAY" environment variable and the plain old Unix X11 way.

There are X11 Servers that run in Windows (I did use XMING (-> http://www.straightrunning.com/xmingnotes/ ) some years ago.

-Michael

As I suggested before, you should first do the porting completely on a Linux PC, avoiding such cut/paste and hundreds of other problems.

As you stated before, that you already have a running PC Linux, Here you have an X-server, the small board can attach to via TCP/IP in the standard UNIX way.

-Michael

22nd October.

I would disagree with this...

If I use any other aplication on the Linux side via VNC I can copy-paste both ways with zero problems.
It i ONLY when I copy something in the Lazarus code editor that I have to first paste this into another application on the Linux side before I go to the Win7 side and paste again and it works. Note that it does not help if I paste it back into the Lazarus editor, it must be done in another Linux editor like the Text Editor.

So:
1) Copy inside Lazarus
2) Paste in Windows - old copied text is pasted

3) Copy inside Lazarus
4) Paste in Linux native text editor - text appears inside the Linux environment
5) Paste in Win7 - correct text appears here too

To me it indicates a problem in the Lazarus text editor, it seems it does not completely handle the Linux clipboard but pasting inside Linux apparently corrects this.

I have earlier reported probnlems with writing special characters like { } [ ] @ \
which requires the use of AltGr to produce where I live. This was explained to me as something with the Lazarus text editor not handling a number of key events transferred through VNC correctly. But that was a different topic since it was about typing on the keyboard.
Here I am dealing with a clipboard problem.

Workaround now is:
------------------
Keep the Linux text editor running and always paste copied text from Lazarus first in that text editor, then in Windows. And for the typing problem I keep { } and [0] and @ in the text so it can be copied and then pasted into Lazarus as needed. Note that these characters can be written no problem via VNC into the Linux text editor....

On Mon, 26 Oct 2015 10:29:35 +0100, Michael Schnell wrote:

This might actually be a bit off topic for this thread, which I created in order to report a Lazarus IDE problem rather than discussing my development issues...
But anyway:

As I suggested before, you should first do the porting completely on a Linux PC, avoiding such cut/paste and hundreds of other problems.

Well, I am not right now that far into the process. I have just briefly tested the class units and checked what would be the caveats there. But then I have switched to laying the ground work first and check if I could actually use FPC in order to:
1) Control relays via the GPIO connector on the RPi2. Done OK

2) Create a TCPIP communications object that would have properties similar to the serial port component I have used in Delphi. THis measn that it must have at least an event for receiving data on the socket. I have tried several approaches and am not yet done. My last try is using Indy TIdTcpClient with some thread to handle the blocking read issues. This is not done and where I am now and since it involves the basic hardware stuff (including ARM7 CPU) I feel it is safer to do directly on the target system. Not yet done.

As you stated before, that you already have a running PC Linux, Here you have an X-server, the small board can attach to via TCP/IP in the standard UNIX way.

Not entirely accurate, what I have are a few VMWare virtual machines with some flavours of Linux Mint installed in order to use for web development testing. So then I need to fire up the VMWare environment too and start the virtual machine in order to get a display that sits inside the VM...

Do you mean that the Linux Mint has an X server that can be used by my Raspbian Jessie on the Pi as the display when they are on the same network?

Or do you mean I should switch away from the Pi and work in the Linux Mint instead?

Before going the VNC route I tried to find an X-server that could be installed in Windows7 so I could use that as the display for the Raspbian Jessie GUI. But it was not as easy as I expected, there were all kinds of caveats concerning those I found so I gave up and tried VNC instead....
Never was able to install and use Xming for example.

Do you have a suggestion as to which X-server I could run on Windows7 instead of using VNC?

Bo Berglund wrote

1) Control relays via the GPIO connector on the RPi2. Done OK

Of course this is rather appropriately done on the target.

2) Create a TCPIP communications object..

This is an example of what should be done on a Linux PC. It does not involve any hardware stuff, as the socket interface is common to all Linuxes.

Any Linux Desktop software uses an X interface as a display. Hence an X server is running. VM now forwards the X-API towards the host OSes display. Nonetheless the X-API the client sees should be perfectly standard and should be usable via TCP/IP.

Do you mean that the Linux Mint has an X server that can be used by my Raspbian Jessie on the Pi as the display when they are on the same network?

I did not try such a thing but this is the paradigm ox X11.

Or do you mean I should switch away from the Pi and work in the Linux Mint instead?

IMHO: in any case when using hardware features of the target are not necessary to do the work at hand.

Never was able to install and use Xming for example.

I once used XMING on WinXP. That did work fine.

Do you have a suggestion as to which X-server I could run on Windows7 instead of using VNC?

IMHO the developing environment for a Linux target should not involve any Windows stuff.

I already provided lots of hints on how the porting might be done, so I can't help with approaches I would not recommend, anyway.

-Michael

Bo Berglund wrote:

Now we're getting somewhere.

Never was able to install and use Xming for example. Do you have a suggestion as to which X-server I could run on Windows7 instead of using VNC?

I think you said you're using PuTTY, so start off with whatever documentation that provides: I'm fairly sure that it integrates with some (but probably not all) versions of Xming.

The issue apparently is that the author of Xming realised that he'd done a good job, and tried to go commercial. The result is that almost everybody settled on using the last "free" version, and that will almost certainly be reflected in what PuTTY works with.

If you had Xming working you'd probably find that it has Xnest, but I'd not suggest using that since it wouldn't solve your c&p problems and if the connection went down you'd lose work.

Alternatively, if you have an OpenSSH client on a Linux desktop system operation should be seamless, but I'm not going into that unless you indicate that it's something you're specifically prepared to explore and even then the linux-other (or possibly fpc-other) list might be a better place.

Michael Schnell wrote

Any Linux Desktop software uses an X interface as a display. Hence an X server is running.

This would probably be a good place to point out (for the benefit of less experienced users) that X's terminology is a bit odd: an "X server" provides graphics services to programs (in the same way that an SQL server provides database services).

So the X server is typically running on the machine on your desktop with the physically-attached screen/keyboard/mouse, even if you've logged into a headless host (e.g. a "server" in a 19" rack) where your programs and source are stored.

The exception to this is when you're running VNC in which case the X server is embedded in the VNC server (i.e. they're linked together into a single binary), and you're talking to this using a VNC client. In this scenario, c&p events have to be sent over the VNC protocol and injected into the X server, hence hopefully into your program.

If you're not running VNC, you can have any number of programs on different hosts but all the UI interaction comes through the single X server on your desktop system. My experience is that things like c&p are seamless /but/ there can be performance problems and on occasion I've seen a debugger getting confused, however if you don't see one of these cases it's to be preferred over VNC.