Let's have a C/C++ project.
Then try to search for usages of any given name in your program - Usages pane is opened automatically.
Then I need to have the contents of this page be copied into the clipboard to use in documentation or elsewhere.
I press Ctrl-A to select all lines, then Ctrl-C to copy.
In my notepad I then press Ctrl-V. Instead of expected list of files (or, maybe, found instances) I have the following:
<...lots of lines are skipped...>
The same happens if I try to copy from the 'Search Results' pane, put the copied content is a bit different, like this:
org.netbeans.modules.search.ResultTreeModel@4293a7[Found 146 match(es) in 50 file(s).]
<...lots of lines are skipped...>
I think this is serious bug, so I prioritize it as P2.
Need to be fixed in 6.8. Does not qualify as P2, but still serious. We need to check if it is C/C++ specific [it does
not look so to me]. If it is not, then needs to be transfered to another component.
There is the same problem with Usages and Search Results in Java.
So it's common problem.
I'd like to NetFIX  this bug. Is it possible?
I see two possible ways to go:
1. copy the HTML that is shown in the "Usages"/"Search" pane
2. copy plain text without colouring or any other markup
The first solution would be easier to implement, but the second one would probably be more practical. So which one to choose?
(Some kind of context menu with the above two options is completely out of scope, I guess.)
Please note that you can actually but both flavors to the clipboard and the target editor might select what it likes to paste when you paste it.
In my opinion it would be better to copy the text with the markup. You can always get rid of it quickly but formatting it is way harder. Would you agree Ondro?
BTW, David Strupl agreed to review & integrate the possible NetFIX patch.
(In reply to comment #6)
> In my opinion it would be better to copy the text with the markup. You can
> always get rid of it quickly but formatting it is way harder. Would you agree
What sounds best to me is what dstrupl mentioned. You copy and when you paste, the client pastes the type it can handle. I copy part of a webpage (with some headers and links) and paste them into a rich text editor (office, keynote) - it gets pasted as rich text. If I past into a simple txt file, only text gets pasted.
I agree. Michael, can you implement it this way?
So I'd have to dive into the Nodes API and deal with DataFlavor, right?
I think I'll give it a try.
You will need Nodes API only in case the results tree is implemented using nodes and explorer - I didn't check that. And yes data flavors are part of the swing clipboard APIs if I am not mistaken. BTW first googling around might give some useful hints regarding clipboard in NetBeans.
It looks like this bug isn't being worked on at the moment, is it ok if I take a shot at it?
In response to Comment #12 : Sure, just assign it to yourself and give it a try. Please attach a patch when you have something worth looking at. If you stop working on it (and its not finished) please assign back to the original alias (email@example.com). Thanks and good luck.
Created attachment 101898 [details]
I've added copy support in the refactoring panel, the same way as it is done for the property sheet api. It supports plain text and html output. I'm not totally happy with the internal classes, but that's the way it is implemented in the property sheets.
Looks good to me. Just a small question: why is the following line commented out?
+// this.plainData = plainData;
I assume you don't have write access, right? If you think that it is ready to be integrated just let me know (assign the bug to myself) and I will apply it for 6.10. Thanks.
(In reply to comment #15) : that's a mistake, I used it during some manual testing. I will attach a new patch and assign it back to you. Thanks!
Created attachment 101919 [details]
The patch has been applied to my team repository as
-- it should reach the main-silver repository today. Marking the issue as fixed. Thanks to everyone involved, especially Ralph for the actual fix.
*** Bug 125275 has been marked as a duplicate of this bug. ***