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.
[dev mar 6, also release 3.3.1 same] If you create a PropertySheet instance outside the event thread - I think it may need to be from the request processor - set a node with some properties using setNodes, then display the sheet in e.g. a NotifyDescriptor dialog: no properties are shown (the "<no properties>" empty panel appears). If created from the event thread, the node's properties are displayed correctly. I believe this is a bug, since generally it is OK to construct Swing components from any thread, provided they are only displayed from the event thread, and only manipulated when visible from the event thread. If this cannot be easily fixed for PropertySheet, please document in its constructor that it ought to be called from the event thread; and/or throw an IllegalStateException from the constructor if !SwingUtilities.isEventThread(). To reproduce: comment out the event-thread check from innertesters/src/org/netbeans/modules/innertesters/InnerCompilerType.java in the beginning of the method warn(String). Now create a build incl. at least innertesters and java modules. Create from template a Classes/Unit-testable Class and try to compile it. You will get a warning that you have not set a base compiler. This might or might not show the property sheet for the inner compiler type correctly. Close the window with OK, leaving the compiler unset. Leave the testable class open in the Editor and focused, and shut down and restart the IDE. As soon as the main window opens, the Java module tries to compute an out-of-date badge for the class -> the compiler type is used -> a warning is displayed. This will show no properties. However pressing F9 after that to compile might show it correctly. If the event-thread check in InnerCompilerType.warn is readded, the properties always appear in the dialog. Attaching a test patch to PropertySheet which shows what it is doing. With or without the fix in InnerCompilerType, a reasonable sequence of steps is shown in the log file: PS.RN.postNodes: nodes=[] PS.RN.postNodes: nodes=[<ITC bean node>] PS.RN.run: nn=<ITC bean node> PS.RN.run/run: nn=<ITC bean node> PS.rPS: node=<ITC bean node> PS.rPS: p=[Lorg.openide.nodes.Node$PropertySet;@50005e PS.rPS: p[0]=Properties PS.rPS: adding pages So the emptyPanel is added in the constructor in the request processor, and apparently then later removed and replaced with the tabbed pane with one property from the event thread. But just the emptyPanel is displayed nevertheless.
Created attachment 4962 [details] Patch which adds some debug printlns
quite interesting bug, sympromatic to the way threads are used in NB. What I figured out is - you are in RequestProcessor thread - you create a PropertySheet, set the current node for it - you display the PropertySheet in a dialog using (indirectly) invokeAndWait - the RequestProcessor thread is now blocked The trouble lies in how "set the current node" is implemented. PropertySheet.setNodes() updates the sheet with a delay in an attempt to coaleace successive updates into one. It does so by schedule a task in the default RequestProcessor. If a new update request comes in quickly then the task is rescheduled. There is only one task. innertesters uses the same RequestProcessor as PropertySheet. If that RequestProcessor is blocked then PropertySheet's task is never run. After pnejedly's rewrite of RequestProcessor-thread mapping (many-to-many instead of the old one-to-one) PropertySheet cannnot even use a private RequestProcessor. My fix is simple: do not use RequestProcessor. javax.swing.Timer does the job perfectly, it even knows how to coalesce tasks. The big question is how can one prevent this type of errors. I think that waiting for user interactions in RequestProcessor is in general a very bad idea. I'll bring this issue on nbdev
Resolved for 3.4.x or earlier, no new info since then -> verified
Resolved for 3.4.x or earlier, no new info since then -> closing.