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.
This problem started in 4.1Beta. We generate both the .form and the .java using wizards outside of Netbeans and then open the form up inside Netbeans. The same generated code that opened up fine in all versions 3 and in 4.0 all of a sudden duplicates the variable section. I spent quite a few hours tracing the problem by debugging Netbeans's source code. I narrowed it down to an exception thrown on line 181 of GuardedDocument because the breakGuarded variable is mysteriously set to false. The exception message is: org.netbeans.editor.GuardedException: Attempt to remove from guarded block at position 3,310. The generated section in our example looks like this: // Variables declaration - do not modify//GEN-BEGIN:variables private com.itgp.mvc.DPanel dPanel; private javax.swing.JLabel lbl_publishers_pubId = new javax.swing.JLabel(); private com.itgp.mvc.view.OTextField publishers_pubId = new com.itgp.mvc.view.OTextField(); private javax.swing.JLabel lbl_publishers_pubName = new javax.swing.JLabel(); private com.itgp.mvc.view.OTextField publishers_pubName = new com.itgp.mvc.view.OTextField(); private com.itgp.extras.ButtonSaveGel ButtonSaveGel = new com.itgp.extras.ButtonSaveGel(); private com.itgp.extras.ButtonClearGel ButtonClearGel = new com.itgp.extras.ButtonClearGel(); private com.itgp.extras.ButtonCloseGel ButtonCloseGel = new com.itgp.extras.ButtonCloseGel(); // End of variables declaration//GEN-END:variables The code when Netbeans 4.1Beta looks like this: // Variables declaration - do not modify//GEN-BEGIN:variables private com.itgp.extras.ButtonClearGel ButtonClearGel; private com.itgp.extras.ButtonCloseGel ButtonCloseGel; private com.itgp.extras.ButtonSaveGel ButtonSaveGel; private com.itgp.mvc.DPanel dPanel; private javax.swing.JLabel lbl_publishers_pubId; private javax.swing.JLabel lbl_publishers_pubName; private com.itgp.mvc.view.OTextField publishers_pubId; private com.itgp.mvc.view.OTextField publishers_pubName; // End of variables declaration // Variables declaration - do not modify private com.itgp.mvc.DPanel dPanel; private javax.swing.JLabel lbl_publishers_pubId = new javax.swing.JLabel(); private com.itgp.mvc.view.OTextField publishers_pubId = new com.itgp.mvc.view.OTextField(); private javax.swing.JLabel lbl_publishers_pubName = new javax.swing.JLabel(); private com.itgp.mvc.view.OTextField publishers_pubName = new com.itgp.mvc.view.OTextField(); private com.itgp.extras.ButtonSaveGel ButtonSaveGel = new com.itgp.extras.ButtonSaveGel(); private com.itgp.extras.ButtonClearGel ButtonClearGel = new com.itgp.extras.ButtonClearGel(); private com.itgp.extras.ButtonCloseGel ButtonCloseGel = new com.itgp.extras.ButtonCloseGel(); // End of variables declaration//GEN-END:variables Here are the different permutations: 1. If I close and re-open Netbeans, most of the time, the FIRST time I open the form the variables are generated correctly. Any time after that (assuming I close and discard changes) I get duplicated variables. 2. If Netbeans is open, and I use the wizard to generate a form, and I try opening it after refreshing the package in the IDE, I get duplicate variables every time I try. 3. If instead of saying "Open" in the context menu I say "Edit" first and THEN press the "Design" button (next to "Source" ) then the variables are generated correctly. 4. Once a form is saved under Netbeans (assuming the variables are not duplicated using one of the techniques above) it will always open fine from that point on. If you need more detail (code sample, stacktrace picture, etc.) please give me an email to send this to. Thanks, David Pociu InsiTech Inc
Created attachment 21738 [details] debug stack trace
Created attachment 21740 [details] source code for wizard-generated .form and .java
Created attachment 21741 [details] XTTC library needed for opening the source
Created attachment 21742 [details] second jar needed to open the form
Created attachment 21744 [details] patch for loading non-NB XMLPropertyEditors (place in {NB41}ide5/modules/patches/org-netbeans-modules-form)
Well, please note that generating forms by yourself is generally unsupported way of forms creation. Anyway I'm reassigning to form module for further evaluation.
Hi David, I can't reproduce the problem with the files you've attached. The .java file already has the variables duplicated. Could you attached the form + java files exactly as they were generated? If I do a change in the form, it is regenerated correctly. I haven't seen the case the duplicated variables would appear again.
Created attachment 21756 [details] updated test case - original generated form from our wizard
Tomas, I attached an original form (test.zip) this morning. Sorry for the previous one - it was getting late yesterday <g> The behavior for me is: 1. Opened NB4.1Beta 2. Generated this form using our wizard 3. NB refreshed the folder automatically and showed the form 4. First time I opened it the variables were generated fine 5. Closed discarding changes, then opened the form again 6. Variables were duplicated. 7. Closing (discarding changes) and re-opening yielded the same variable duplication on subsequent opens 8. Opening with "Edit" instead of "Open" and once the source code shows going to "Design" is the only thing that works correctly at this point and eliminates variable duplication. A few more pointers - in my testing this problem occured probably 90-95% of the time. But not 100% of the time - which is a bad thing for reproducibility - so I'm suspecting some multi-threading timing issues - just a gut feeling. The real problem is in the PositionBounds class in this method: public void setText(final String text) throws IOException, BadLocationException { final CloneableEditorSupport editor = begin.getCloneableEditorSupport(); final StyledDocument doc = editor.openDocument(); final BadLocationException[] hold = new BadLocationException[] { null }; Runnable run = new Runnable() { public void run() { try { int p1 = begin.getOffset(); int p2 = end.getOffset(); int len = text.length(); if (len == 0) { // 1) set empty string if (p2 > p1) doc.remove(p1, p2 - p1); } else { // 2) set non empty string // [MaM] remember doclen to compute new length // of the inserted string (the length changes // because insertString removes \r characters // from it) int docLen = doc.getLength(); if (p2 - p1 >= 2) { doc.insertString(p1 + 1, text, null); // [MaM] compute length of inserted string len = doc.getLength() - docLen; doc.remove(p1 + 1 + len, p2 - p1 - 1); doc.remove(p1, 1); } else { // zero or exactly one character: // adjust the positions if they are // biased to not absorb the text inserted at the start/end // it would be ridiculous not to have text set by setText // be part of the bounds. doc.insertString(p1, text, null); // [MaM] compute length of inserted string len = doc.getLength() - docLen; if (p2 > p1) doc.remove(p1 + len, p2 - p1); if (begin.getOffset() != p1) begin = editor.createPositionRef(p1, begin.getPositionBias()); if (end.getOffset() - p1 != len) end = editor.createPositionRef(p1 + len, end.getPositionBias()); } } } catch (BadLocationException e) { hold[0] = e; } } }; NbDocument.runAtomic (doc, run); if (hold[0] != null) throw hold[0]; } Basically the code gets to this point: if (p2 - p1 >= 2) { doc.insertString(p1 + 1, text, null); and then insertString throws the BadLocationException and does not allow the remove to continue - therefore the old code stays in. The stacktrace for that should be in the first picture attached. Thanks for your help as usual, David
I still can't reproduce the problem - the guarded block is always regenerated well for me. It seems to be defined correctly in the java file. Maybe there is really some race condition. Anyway, form editor seems to pass right text to the section (it appears there) - just the old content is not removed. Mila - could you evaluate this? Any idea why it happens?
Created attachment 21802 [details] ant.jar
Strange, the breakGuarded should not be false in the given stacktrace. I have looked into the code and I have found a potential deficiency in the GuardedDocument.runAtomic() implementation that might cause this problem. dpociu, if I attach a diff are you able to apply it and make a test build?
Sure, but check this out first: The problem went away when I updated to JDK 1.5.0_02 (latest) and NB 4.1RC1. (I had the original 1.5.0 and 4.1Beta before). With these settings I cannot duplicate it on any other computer in the office either. I uninstalled 4.1Beta, but if you think it's worth it I can put it back in and try it if it will help you. Thanks for your help, Dave
Created attachment 21809 [details] Diff to be applied in nb_all/editor directory
Is this really P1 priority, as I understand user is using parts on NetBeans code outside of IDE.
If you can make the problem to go away it's fine I will integrate my patch to the main trunk only. Putting it back into NB4.1 codebase would be rather complicated at this late time. To Milan: I agree that this is not P1 as it's a non-standard usage but it revealed a potential inconsistency in the code that might be triggered in other cases too.
Fixed in main trunk: Checking in libsrc/org/netbeans/editor/GuardedDocument.java; /cvs/editor/libsrc/org/netbeans/editor/GuardedDocument.java,v <-- GuardedDocument.java new revision: 1.18; previous revision: 1.17
Downgrading to P3