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.
The Paste action can become disabled if there is just one file opened in the editor (for more files it usually does not happen). We've made a research with Mato and we have found that in CloneableEditor the setPasteTypes(null) is called which makes the PasteAction disabled. The log is attached. Debugging legend in the log: "enab:" means the status of the system Paste action "enabled:" means the status of the editor's Paste action
Created attachment 7033 [details] Debugging log
Hi, althought I said to Mila that the paste action is enabled for more than one file, now I found that this is not always true. Sometimes it is disabled when just one file is opened and enabled when more files are opened. Sometimes, it is disabled/enabled in both cases. But, these steps seems to be reliable: 1. Start brand new IDE (clean userdir). 2. Close welcome 3. Open examples/colorpicker/ColorPreview 4. Select piece of code, choose Copy from pop-up 5. Open Pop-up menu in editor, the Paste is disabled. 6. Create a new class (Main java class) 7. Open pop-up menu in editor, the Paste is enabled. I found even another problem (this seems to be more reproducible): 1. Go into the explorer. 2. Cut some file. 3. Go into the editor, select piece of text. 4. Open pop-up menu in editor - Cut&Copy are disabled. 5. Paste the node somewhere in the explorer. 6. Select a piece of text in the editor. 7. Open pop-up menu in editor: the Cut&Copy actions are enabled.
Here is the evaluation: CloneableEditor is fine, it tries to update system paste action according the clipboard content, whenever the cut/copy was perfomed. But the problem is it doesn't get the proper results. The issue has two parts: 1) one is there is not working lookup correctly (see #issue 26339) 2) second one the NbClipboard#getContents with the slowSystemClipboard doesn't work correctly. NbClipboard uses slowSystemClipboard property, which in case is set (our case), then the getContents returns bad result (null). If the property is switched off, the getContents() method works fine. Passing to Trung. As I remeber the property was put there due to a performance reasons. Maybe it could be removed, there was made a change aferwards, which accesses the clipboard outside the AWT thread (originally it caused deadlocks by DnD, the change was done on two places ExplorerActions, and CloneableEditor). I think the accesssing the clipboard whitin the AWT could have been the main problem. However I didn't measure it now.
Raising priority because this issue affects one of the important IDE validation tests.
We will have to investigate. Currently I don't understand why pzavadsky thinks that NbClipboard doesn't work correctly. Workaround in the meantime: -J-Dnetbeans.slow.system.clipboard.hack=false
It seems it is fixed in builds 20030114 and later. It stopped to happen in automated tests and I cannot reproduce it manually either.
Peter, have you fixed it by new actions implementation?
Yes, the changes in actions could fixed this, it changes all above said. If some similar problem occures, please create a new issue.
It works fine in [nb_dev](20030728) - verifying.