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