This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Creating file copy by ctrl+c ctrl+v doesn't work in Projects panel. 1. Open projects panel. 2. Select any file (foobar.txt) and press ctrl+c 3. Press ctrl+v >> Expected: new file with name foobar_1.txt or foobar_copy.txt is created. >> Actual: Nothing happens. As a workaround it is possible to select parent folder of the file and press ctrl+v but the commons OSes behaviour that you can create a copy of file by just pressing ctrl+c ctrl+v.
*** Bug 249336 has been marked as a duplicate of this bug. ***
The workaround is not working either. Nothing happens. I have this behaviour since version 8 on at least three computers (all win7) The Netbeans 7 version is working fine as it should
(In reply to eduh12 from comment #2) > The workaround is not working either. Nothing happens. I have this behaviour > since version 8 on at least three computers (all win7) The workaround works fine for me with NetBeans 8 and development version. Please, what project type do you use? Is it broken for all types of files, or just some specific type? Thank you.
That is the version with PHP Product Version: NetBeans IDE 8.0.2 (Build 201411181905) Updates: Updates available to version NetBeans 8.0.2 Patch 1 Java: 1.7.0_71; Java HotSpot(TM) Client VM 24.71-b01 Runtime: Java(TM) SE Runtime Environment 1.7.0_71-b14 System: Windows 7 version 6.1 running on x86; Cp1252; en_US (nb Also tried the HTM5Application but same error. Nothing happen when clipboard is empty or it just pastes previous content from other application into the editor. Tried several ways included the workaround. As said: netbeans7.0 does do it right.
> Also tried the HTM5Application but same error. Nothing happen when clipboard is > empty or it just pastes previous content from other application into the > editor. I guess this bug is not related to the originally reported issue, which is related to copying and pasting files in Projects and Files views. Anyway, the problem with text in clipboard is slightly similar to bug 247585. What other applications are running on your computer? E.g. Adobe Reader can affect NetBeans clipboard.
I have adobe reader. Uninstalled it but with no success. Also tried to run Netbeans with elevated admin rights but with no success. Looks like copy actions in the projects panel do not succeed at all and leave the clipboard in a previous state. I have two win7 64bits computers which are different and very minimal equipped. Netbeans7 is OK where Netbeans8 fails and is rather unusable due to this bug.
http://hg.netbeans.org/core-main/rev/a8d0ac827c07 Fixed (the copy and immediate paste, not the Win8 clipboard problem). Thank you for reporting.
> Looks like copy actions in the projects panel do not succeed at all and > leave the clipboard in a previous state. I tested it on Windows 10 and everything worked fine. I'll also try Windows 8.
(In reply to Jaroslav Havlin from comment #8) > I'll also try Windows 8. Clipboard in NetBeans (development version) works fine for me on Windows 8. I'm sorry, I have no idea what could be wrong.
(In reply to Jaroslav Havlin from comment #9) > (In reply to Jaroslav Havlin from comment #8) > > I'll also try Windows 8. > Clipboard in NetBeans (development version) works fine for me on Windows 8. > I'm sorry, I have no idea what could be wrong. Hi, As listed my problem occurs on windows 7
Integrated into 'main-silver', will be available in build *201510210002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/a8d0ac827c07 User: Jaroslav Havlin <jhavlin@netbeans.org> Log: #250134: Copy file and immediate paste doesn't work
> Hi, > As listed my problem occurs on windows 7 I work on Windows 7 quite often (mostly with development version of NetBeans), and I haven't experienced such problems with clipboard. I'm sorry, I need some reproducible test case.
Huree. Just downloaded the netbeans-trunk-nightly-201510220002-php-windows-x64.exe and copy paste is working on my win7 64 bit computer. Tomorrow will test some other computers.
> [...] and copy paste is working on my win7 64 bit computer [...] Good news, thank you. Please try also NetBeans 8.1 Release Candidate 2, which can be downloaded at [1]. If the clipboard is working fine in development build, but does not work in 8.1 RC2, please let us know. [1] http://download.netbeans.org/netbeans/8.1/rc2/
Hi, Alas.......clipboard is not working is NetBeans 8.1 Release Candidate 2.
Strange. 8.1 RC 2 works fine for me as well on Windows 7. I can only think of cleaning the userdir, updating JDK, or keeping with the Development build (which is in fact very similar to 8.1).
Will test in near future with two other compu's and let you know.
It is getting a bit weird. The dev version is OK. I updated to latest JDK and cleaned up and now the NetBeans 8.1 Release Candidate 2. is behaving differently....a little bit better but not as it should. Using CTRL+C and CTRL+V does not work directly. However this is: Use CTRL+C , move mouse to 'any' folder and do CTRL+V ...then the file is copied. The focus is then on the file so a next CTRL+V does not work unless you move the mouse again to a folder......
(In reply to eduh12 from comment #18) > ....a little bit better but not as it should. > Using CTRL+C and CTRL+V does not work directly. This is expected behavior for 8.1. The "copy and immediate paste" enhancement will be available in the next release (or in current development builds). Thank you for help.
FYI, tested the latest dev build and the 8.1 rc2 on two other win7 64bit boxes. Same behaviour as described before so dev=ok and rc2 works only when pasting from a folder.
The fix for this, now has the potential for causing infinite loops/stackoverflow exceptions when the parent node of a DataNode is NOT a FolderNode, but instead is another DataNode (wrapped by a FilterNode). The stackoverflow exceptions arise from the implementation of DataNode.getPasteTypesFromParent(Transferable t) which uses the Node's parent instead of the DataObject/FileObject's parent. Thus, the fix would be to get the directory/Folder of the DataNode and paste in that same folder as opposed to getting the Node's parent which may NOT be the FolderNode. There are cases where the ProjectLogicalView does not match the exact Folder/Directory structure, and in those cases infinite loops will occur. Hence, I recommend getting the FileObject/DataObject's parent instead of the Node's parent. StackOverFlow Exception: at org.openide.loaders.DataNode.getPasteTypesFromParent(DataNode.java:360) at org.openide.loaders.DataNode.createPasteTypes(DataNode.java:337) at org.openide.nodes.AbstractNode.getPasteTypes(AbstractNode.java:543) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.loaders.DataNode.getPasteTypesFromParent(DataNode.java:360) at org.openide.loaders.DataNode.createPasteTypes(DataNode.java:337) at org.openide.nodes.AbstractNode.getPasteTypes(AbstractNode.java:543) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.loaders.DataNode.getPasteTypesFromParent(DataNode.java:360) at org.openide.loaders.DataNode.createPasteTypes(DataNode.java:337) at org.openide.nodes.AbstractNode.getPasteTypes(AbstractNode.java:543) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.loaders.DataNode.getPasteTypesFromParent(DataNode.java:360) at org.openide.loaders.DataNode.createPasteTypes(DataNode.java:337) at org.openide.nodes.AbstractNode.getPasteTypes(AbstractNode.java:543) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.loaders.DataNode.getPasteTypesFromParent(DataNode.java:360) at org.openide.loaders.DataNode.createPasteTypes(DataNode.java:337) at org.openide.nodes.AbstractNode.getPasteTypes(AbstractNode.java:543) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.loaders.DataNode.getPasteTypesFromParent(DataNode.java:360) at org.openide.loaders.DataNode.createPasteTypes(DataNode.java:337) at org.openide.nodes.AbstractNode.getPasteTypes(AbstractNode.java:543) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.loaders.DataNode.getPasteTypesFromParent(DataNode.java:360) at org.openide.loaders.DataNode.createPasteTypes(DataNode.java:337) at org.openide.nodes.AbstractNode.getPasteTypes(AbstractNode.java:543) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.loaders.DataNode.getPasteTypesFromParent(DataNode.java:360) at org.openide.loaders.DataNode.createPasteTypes(DataNode.java:337) at org.openide.nodes.AbstractNode.getPasteTypes(AbstractNode.java:543) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.loaders.DataNode.getPasteTypesFromParent(DataNode.java:360) at org.openide.loaders.DataNode.createPasteTypes(DataNode.java:337) at org.openide.nodes.AbstractNode.getPasteTypes(AbstractNode.java:543) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:691) at org.openide.loaders.DataNode.getPasteTypesFromParent(DataNode.java:360) at org.openide.loaders.DataNode.createPasteTypes(DataNode.java:337) Caused: org.openide.util.RequestProcessor$SlowItem: task failed due to at org.openide.util.RequestProcessor$Task.schedule(RequestProcessor.java:1484) at org.netbeans.modules.openide.explorer.ExplorerActionsImpl$ActionStateUpdater.schedule(ExplorerActionsImpl.java:894) at org.netbeans.modules.openide.explorer.ExplorerActionsImpl$ActionStateUpdater.flavorsChanged(ExplorerActionsImpl.java:832) at sun.reflect.GeneratedMethodAccessor63.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.openide.util.WeakListenerImpl$ProxyListener.invoke(WeakListenerImpl.java:487) at com.sun.proxy.$Proxy11.flavorsChanged(Unknown Source) at org.netbeans.NbClipboard.fireChange(NbClipboard.java:353) at org.netbeans.NbClipboard$GetContents.run(NbClipboard.java:457) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443) at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:68) at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303) [catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2058) I have an RCP application which did not generate stackoverflow exceptions before this commit, but, now generates StackOverflow errors due to have a DataNode that has children that are other DataNodes. My app has this node structure because I have text files(DataNodes) in my project that has links to other text files inside or external to my project. Hence it is convenient for me and my users to show those references by having them be children nodes(wrapped as FilterNodes on the DataObjects being referenced by the parent file).
Patch recommendation: # This patch file was generated by NetBeans IDE # It uses platform neutral UTF-8 encoding and \n newlines. --- a/DataNode.java +++ b/DataNode.java @@ -350,21 +350,11 @@ * @param t The transferable. * @return List of parent node's paste types (can be empty). */ - private List<PasteType> getPasteTypesFromParent(Transferable t) { - if (t instanceof Lookup.Provider) { - Lookup l = ((Lookup.Provider) t).getLookup(); - Node n = l.lookup(Node.class); - if (n != null) { - Node parentNode = n.getParentNode(); - if (parentNode != null) { - PasteType[] pts = parentNode.getPasteTypes(t); + private List<PasteType> getPasteTypesFromParent2(Transferable t) { + PasteType[] pts = obj.getFolder().getNodeDelegate().getPasteTypes(t); PasteType[] updated = updateParentPasteTypes(pts); return Arrays.asList(updated); } - } - } - return Collections.emptyList(); - } @NbBundle.Messages({ "# Text appended to action name so that it is clear that the action",
At a minimum, make DataNode.getPasteTypesFromParent(...) protected so that users can override the behaviour if they have a DataNode that has children that are other DataNodes. I suppose I can always override DataNode.createPasteTypes(...), thus DataNode.getPasteTypesFromParent(...) will never be called as a workaround.
So I realized you can't use obj.getDataFolder()... from the DataNode and that you have to use the Lookup.Provider on the Transferable. So ignore early patch suggestion. Better working/tested approach is: private List<PasteType> getPasteTypesFromParent(Transferable t) { if (t instanceof Lookup.Provider) { Lookup l = ((Lookup.Provider) t).getLookup(); Node n = l.lookup(Node.class); if (n != null) { FileObject f = n.getLookup().lookup(FileObject.class); if (f != null) { FileObject parentFO = f.getParent(); if (parentFO != null) { try { DataObject parentDO = DataObject.find(parentFO); PasteType[] pts = parentDO.getNodeDelegate().getPasteTypes(t); PasteType[] updated = updateParentPasteTypes(pts); return Arrays.asList(updated); } catch (DataObjectNotFoundException ex) { Exceptions.printStackTrace(ex); } } } } } return Collections.emptyList(); }
Thank you very much for reporting and for suggestions. > when the parent node of a DataNode is NOT a FolderNode, but instead is another > DataNode (wrapped by a FilterNode). I'm sorry, I haven't realized this use case, which is perfectly valid. > Hence, I recommend getting the FileObject/DataObject's parent instead of the > Node's parent. This would work fine in majority of cases, but in some cases it could behave in unexpected ways. In fact, getting parent from Node layer (in contrast to Filesystem layer) was intentional. The case I had in mind is "Project Files" node. Invoking "Paste" action on one of nodes under "Project Files" would paste clipboard content to parent folder of that file, but result of that action might not be immediately visible (if the pasted file is not considered to be a project file), which is wrong from UI perspective. + Paste action on Java file node should invoke refactoring instead of standard file-system copy operation. I'd rather keep current behavior + add check to ensure that parent node represents a folder. It is not very elegant, but it should do what we need. (Increasing priority and changing issue type to Defect, as the reported problem is a regression.)
Created attachment 159085 [details] Sketch of fix Sketch of fix. I'll need to test it and consider if there are better solutions. Could you please review the patch? Would it work for you? Thank you.
(In reply to Jaroslav Havlin from comment #26) > Created attachment 159085 [details] > Sketch of fix > > Sketch of fix. I'll need to test it and consider if there are better > solutions. > > Could you please review the patch? Would it work for you? > Thank you. Yes, your proposed fix should prevent infinite loops. I agree with your statements in the earlier comment as well.
Fixed: http://hg.netbeans.org/core-main/rev/9b847f8feb5c Thank you for help!
Integrated into 'main-silver', will be available in build *201604170001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/9b847f8feb5c User: Jaroslav Havlin <jhavlin@netbeans.org> Log: #250134: Copy file and immediate paste doesn't work
Hi, Since I reported duplicate bug 249336 I tested this fix. But unfortunately the behaviour is still the same and copy\paste does not funtion as expected. I use Product Version: NetBeans IDE Dev (Build 201604170001) Java: 1.8.0_60; Java HotSpot(TM) 64-Bit Server VM 25.60-b23 Runtime: Java(TM) SE Runtime Environment 1.8.0_60-b27 System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb)
> Since I reported duplicate bug 249336 I tested this fix. > But unfortunately the behaviour is still the same and copy\paste > does not funtion as expected. Hello, it works fine for me in that build (downloaded from [1]). Can you please describe exact steps to reproduce the issue? (Active window/panel, file types, UI actions/keyboard shortcuts invoked, etc.) Thank you. [1] http://bits.netbeans.org/dev/nightly/2016-04-17_00-01-48/
Hi, A made some screendumps of my actions to replicate the problem. http://www.eduh.nl/netbeans/netbeans.html Basically: select a file in the nav panel, CTRL+C (or use rightmouse). During that action the cursor looses focus and shifts to the edit panel. CTRL+V will copy any contents of previous clipboard in the edit panel. Notice that in rightmouse menu the 'Paste' option is greyed out. In netbeans7 there was no problem and I once had a patched 8.? version which solved the problem but that fix seems to be lost.
Hi, Just got a brand new laptop win7 64x and installed latest build. Now copy\paste of files in the nav window works out of the box. Then I discovered a tricky thing. I use for a long time this handy plugin http://plugins.netbeans.org/plugin/53723/one-click-open-sesame and voila....on activation the copy\paste issues are back again. In one of the many builds I tried I had a working copy\paste + a working opensesame. For now I will report the problem on github where the plugin is maintained.
Unfortunately I just found out that this issue fixes only files and not folders. Instead of reopening, I have reported that as a new issue #267581. Thanks.