Copy & Paste isn't working?

[NerdIII]

I just found when I compile the latest GIT trunk version on my Gentoo with gcc-4.4.4 Ctrl-V doesn't work. Specifically it seems to erase the clipboard content if it is content from Code::Blocks prior to the actual paste (which is an empty string then). Pasting works if the content comes from a foreign application like a text editor. Maybe it's just some odd constellation on my side like using the default wx skin or some system setting, but I would be glad to hear if you devs see the issue too or not. I saw in the commit log that there was an update to the editor component which could be related. I would really stick with the official release if it wasn't for the great improvements to the code completion plugin in the git trunk 

[ollydbg]

works here under windows XP rev 6877.
where is the git trunk??? I only know the svn trunk.

[Jenna]

Confirmed on debian 64-bit svn r6876.

I will look into it.

Thanks for reporting this issue.

By the way copying from C::B to an external app also works.

[oBFusCATed]

Probably this is the cause: http://svn.berlios.de/wsvn/codeblocks/?op=revision&rev=6876&peg=6876

[Jenna]

Probably this is the cause: http://svn.berlios.de/wsvn/codeblocks/?op=revision&rev=6876&peg=6876

I think that's what the OP meant:

I saw in the commit log that there was an update to the editor component which could be related.

[Jenna]

The issue should be fixed in svn now (svn r6878).

[NerdIII]

works here under windows XP rev 6877.
where is the git trunk??? I only know the svn trunk.

I mixed it up with another package I installed recently that uses git, sorry for the confusion 
And thank you for the quick fix, Jens!

[Jenna]

My second commit (svn r6879) breaks replacing a selected text.
It seems the whole clipboard is cleaned, even if the middle-paste stuff only uses the so called primary clipboard (on wxGTK).
So I disabled selecting and pasting with middle-mouse-button again, until we find a solution for the issue.

[killerbot]

My second commit (svn r6879) breaks replacing a selected text.
It seems the whole clipboard is cleaned, even if the middle-paste stuff only uses the so called primary clipboard (on wxGTK).
So I disabled selecting and pasting with middle-mouse-button again, until we find a solution for the issue.

yes, just bumped into this issue, that was nasty .

[ultimA]

A similar issue seems to be present in the past nightlies too. It is present also in svn7006. I have to try copying something from the code editor 4-5 times before I actually succeed in pasting the same thing. If I try to cut, the original is gone as it should, but then I cannot paste it until I try again cutting (after undo) a few more times. Using Arch Linux.

[ultimA]

Please fix this error, it is the same as described in the opening post but it still persists on Linux in rev7040. Not being able to use copy inside CB prevents me from using the IDE at all.

[Jenna]

Please fix this error, it is the same as described in the opening post but it still persists on Linux in rev7040. Not being able to use copy inside CB prevents me from using the IDE at all.

Do you use a self-compiled C::B or a binary distribution ?
Which version of wxWidgets do you use, and which version is used to compile C::B (see "Help -> About") ?

It works flawlessly here on debian 64-bit.

[ultimA]

It is self-compiled, in the sense that it is a user-respository package for Arch linux that checks out the latest svn, compiles and installs it. The only binary available on Arch is for CB 10.05.

The About dialog tells me: "wx2.8.11 (Linux, unicode) - 64bit"

I looked at the package definition to be able to tell you how it is exactly compiled. It checks out the trunk, then it does:
  ./bootstrap
  ./configure --prefix=/usr --with-contrib-plugins=all
  make

Let me know if there is any other way I can help debugging.

[ultimA]

Today I tried to look at the clipboard bug myself, why isn't it working correctly. There is something strange in the CB code that I have found, in ScintillaWX.cpp, line 544-551 (rev 7076):

Code

#ifdef __WXGTK__
		for(int i=0; i<5; i++) {
			//wxPrintf(wxT("Copying to clipboard %ld\n"), i);
        	CopyToClipboard(st);
		}
#else
     	CopyToClipboard(st);
#endif

So basically, only if compiling for wxGTK, blindly repeat every copy operation to the clipboard 5 times. WTF?!

I guess some developer, whoever it was, must have met the same issue as I am experiencing right now (the reason for this thread), he also have noticed, that clipboard operations on wxGTK only work reliably if repeated some number of times. So he just built a loop around it. Unfortunately, it is still not working for me, I have to manually hit ctrl-c multiple times if I want a copy operation to succeed.

Now, I am NOT suggesting increasing the loop count. But rather, plz someone figure out what the real problem is. Why am I not doing it myself? Because I have no idea about GTK or wxWidgets (I never used their APIs before), and for someone who knows these libraries it would probably only take a neglible amount of time to check the CopyToClipboard(...) method. Anyway, that loop-5-times-or-else-it-does-not-work thing looks really crazy to me, not just because it is a questionable hack, but it obviously doesn't solve the problem.

Thank you.

[ollydbg]

using the blame function of SVN, then found it was change in:

Code

killerbot  2008-8-16 2:15:17             
* copy/cut-paste fixes in linux
* copy/move fixes on linux when drag and drop of selected text with the mouse

[CronosTs]

Hi How are you? So I also have this problem, I honestly do not know what to do,

Usage: Codeblocks 10:05
The Arc linux


I look Responder

[schizofrenikh]

I confirm this bug on Debian amd64 testing 15 of may 2011. This is occurring with both 10.05 form official repositories and the one from apt.jenslody.de.
Maybe its connected with some other library rather than codeblocks itself?

I encountered the problem after one of recent updates I made. I attach my apt log. Maybe it will be useful somehow.

[Jenna]

Now, I am NOT suggesting increasing the loop count. But rather, plz someone figure out what the real problem is.

I think I found the cause, but it's a wxWidgets bug and I'm not sure if we can find a really reliable workaround inside C::B.
I just opened a ticket on wxWidgets.org: http://trac.wxwidgets.org/ticket/13245.

Let's see what happens.

[killerbot]

using the blame function of SVN, then found it was change in:

Code

killerbot  2008-8-16 2:15:17             
* copy/cut-paste fixes in linux
* copy/move fixes on linux when drag and drop of selected text with the mouse

this solution back then (which did solve the issue then as far as I can recall) was handed over by Eranif (if I remember well), the guy who develops CodeLite.

I am not up to speed with the current issue, is it something recently new, has it to do with the fix from 2008 or got that fix reverted in the meantime due to other updates ? Anyone with the full picture ?

[Jenna]

using the blame function of SVN, then found it was change in:

Code

killerbot  2008-8-16 2:15:17             
* copy/cut-paste fixes in linux
* copy/move fixes on linux when drag and drop of selected text with the mouse

this solution back then (which did solve the issue then as far as I can recall) was handed over by Eranif (if I remember well), the guy who develops CodeLite.

I am not up to speed with the current issue, is it something recently new, has it to do with the fix from 2008 or got that fix reverted in the meantime due to other updates ? Anyone with the full picture ?

No, it's not reverted and the bug seems to occur only with some window-managers (on gnome 3 I never saw it, but on xfce it often happens).
Unfortunately it is not really fixed by my patch for wxWidgets (even if the code is wrong without it anyway).
On my test-xfce (without eranif's patch/hack) it happens only every 20 or 30 times at the moment (not every second as before), but it should work reliable.

[Jenna]

The wxWidgets changes I posted do definitely not fix the issue.

I attach a patch that hopefully is a better workaround than the hack we have in trunk at the moment.

I also build a test-version for debian/ubuntu and added it to my repo.

If you want to use apt (or dselect, synaptic or whatever) you need to add the following entries to /etc/apt/sources.list :

Code

deb http://apt.jenslody.de/ any test
deb-src http://apt.jenslody.de/ any test

and remove entries for the normal nightlies, debugger branch or release.

Alternatively you can download the deb's directly from http://apt.jenslody.de/pool/test/c/codeblocks/ .

[schizofrenikh]

Big THANKS for taking care of this bug.
It's really annoying and I though it was forgotten.

1. I confirm the bug is not fixed in the version provided by jens. It's still present on my up to date debian wheezy installation and build 7157 from jens test repository. It's even worse now. When checking for presence of this bug I do a lot of copy/paste. Usually the data is pasted correctly, sometimes it is not pasted(one in 3 to 5 tries), but on rare occasions(but enough often to reproduce the behavior in less than a minute, ~ones in 50 tries) the whole application crashes and gives me an option to send some crash log(sometimes it doesn't, it just disappears). I sent the log twice.
2. I confirm using xfce4. Moreover after checking the apt-get log i found that quite some packages for both gtk and xfce4 were updated. Especially xfce looks much different than previous version. The problem is with both stable and testing builds of C::B and I think the stable one worked well before the updates.

EDIT: added info about crashes

[Jenna]

1. I confirm the bug is not fixed in the version provided by jens. It's still present on my up to date debian wheezy installation and build 7157 from jens test repository.

Which output do you get in C::B's log, if you copy some text to the clipboard ?

[schizofrenikh]

here is the log and crash report.
I was using C::B with xfce.
The crash happened on copy/paste tries.

[BuBuaBu]

I made some research on google, and find some interesting talk :

https://bbs.archlinux.org/viewtopic.php?id=113100
https://bugs.launchpad.net/inkscape/+bug/418242

So, according to these threads, the bug is cause by some app, like clipman and xfce4-settings-helper on XFCE
That could explain why we havn't it on gnome desktop

[schizofrenikh]

The problem just vanished.
I checked the log and found updates:
xfce4-settings:amd64 (4.8.1-4, 4.8.2-1)
xfce4-session:amd64 (4.8.1-2, 4.8.1-3)
among many others but these are the most suspicious in the light of what BuBuaBu posted.

The tested version was 7157 from jens repos. I get a message that 0 retries were needed in Code::Blocks tab under logs&others I will check newer build later. I work both with clipboard helper on and off.

Thank you everybody for your help. I hope this problem won't come back again.

[BuBuaBu]

Indeed, new xfce-settings version has been released !
in the change log :
- Start using the gsd clipboard manager again (bug #7588)

I read different bug in xfce bugzilla, but nothing like ours.

I check wxscintilla, wxGTK and xfce source code, but can't find the reason.

Hope this will not happen again.

[oBFusCATed]

I've bumped in this issue while debugging this https://sourceforge.net/p/codeblocks/tickets/524/
Which is the same as this one http://forums.codeblocks.org/index.php/topic,22033.0.html
And it is pretty easy to reproduce with the ubuntu 17.04 release.

After some digging I've reverted most patches related to the original issue described in the topic and it seems everything works correctly (after a little addition to ClaimSelection to not use the primary clipboard in wx2..

The changes could be found in the experiments/copy_paste branch in my github repo: https://github.com/obfuscated/codeblocks_sf/tree/experiments/copy_paste
I'll be happy if more people test this, before I push it to the svn trunk.

I've tested this on ubuntu 17.04, gentoo+enlightenment (wx2.8 and wx3.0). Tomorrow I'll test centos6+wx28. So testing anything that is different from these combinations will be very welcome.