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.

Bug 21241 - PropertySheet misbehaves when created outside event thread
Summary: PropertySheet misbehaves when created outside event thread
Status: CLOSED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Explorer (show other bugs)
Version: 3.x
Hardware: PC Linux
: P4 blocker (vote)
Assignee: _ ttran
URL:
Keywords: THREAD
Depends on:
Blocks:
 
Reported: 2002-03-06 13:38 UTC by Jesse Glick
Modified: 2008-12-22 18:19 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Patch which adds some debug printlns (3.45 KB, patch)
2002-03-06 13:39 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2002-03-06 13:38:29 UTC
[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.
Comment 1 Jesse Glick 2002-03-06 13:39:17 UTC
Created attachment 4962 [details]
Patch which adds some debug printlns
Comment 2 _ ttran 2002-03-22 08:51:59 UTC
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
Comment 3 Quality Engineering 2003-07-01 15:50:40 UTC
Resolved for 3.4.x or earlier, no new info since then -> verified
Comment 4 Quality Engineering 2003-07-01 16:39:48 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.