NB build 200303280100, Nevada build 030325, JDK
1. Start the IDE (clean userdir)
2. Open Tools/Options dialog.
3. Open "Debugging and Executing/Execution Types".
4. Click on "Debugger Execution".
5. You can see that the property sheet is blinks
6. It seems that this happens always when:
a) You open some node and click on any of the
children for the first time.
b) After this first time, all children will be
always paint correctly.
c) If you close and open the parent, again the
first click on any child causes re-draw.
It seems to me that the problem occured between
builds 200303110100 and 200303111847 (I am able to
reproduce this problem on 200303111847 and I was
not able reproduce it on 200303110100).
I'd hazard a guess that something sets the selected node to null
and then back to the selected node - if it only happens in the
options dialog, the problem is probably in SettingsChildren or
something such. To test this theory, add some logging and
stack traces in PropertySheet.setNodes().
It could also conceivably happen if one of the properties
fires a property change with a null source *at the time it is
selected*, although it should not blank the sheet.
Setting this issue to block the propertysheet rewrite umbrella
task - if it is indeed a bug in property sheet, it will surely
be fixed once the new one is integrated. Since this is a P3,
it will not be fixed for 3.5, but for 4.0 - I'd rather not do
any further maintenance on the current property sheet code, since
we will throw it away soon. If you feel strongly that this needs
to be fixed immediately, please raise the priority.
Honza isn't right, problem occured between builds :
200303162350(does not work correctly)
In our opinion is caused by fix made by Jirka :
because it's a typical regression rise priority to P2.
Thanks To Honza Chalupa and other for help.
I forget to point out that Jirka's fix fixed issue 27781.
Also (may or may not be related):
[dev 030325] Expand the Modules node in Options. Optionally, set
Sorting mode to something other than By Category, so that there is no
substructure, just a long list of modules. Click on one at the top;
its prop sheet shows. Press Down arrow. Next one shows, with its prop
sheet; fine. Press and hold Down arrow. Selection moves down quickly
over several items. Release the key; selection stops and prop sheet
for current node shown; fine.
Now click on a node at the top and press Down repeatedly quickly (a
few times a second), not holding it down. Each time you press it, the
property sheet half of the Options window (as well as the global
property sheet) flickers: first the sheet is drawn to say "<No
Properties>" with no tabs (i.e. be blank), then it is immediately
redrawn to show the properties for that node. This gives a disturbing
visual effect and probably slows down repainting.
Note that if you do the same repeated selection movement in the main
Explorer tree view, the problem does not occur. The property sheet
changes every time you press the arrow key, *but* it just repaints
what it needs to repaint (looking smooth) and does not temporarily
display the empty property sheet.
Marian: we are probably right both. The builds I tested were trunk
builds (I ought to write it, but I forgot) and yours are NB3.5. I am
definitely able to reproduce the problem on 200303111847 trunk build.
Evaluation: The noted change of PropertySheet initiates delaying
changes in sheet. That way is:
1st change --> update sheet immediately
2nd change --> schedule update for 70ms
n-th change --> reschedule update for 100, 200, ..., max 350 ms
This delayer works correctly.
Problem occurs because PropertySheet is overloaded by
SelectedNodesChange events. Every change of selected node in
TreeTableView generates 4 events. Two events informs that no node is
selected, next two informs about new node selected. (i.e. 1st event ->
immediately empty sheet is displayed, 3rd event -> sheet is displayed
This problem is that TreeTable clears selection on every update
I can do a hot fix in PropertySheet, 1st change will be scheduled too,
no redraw will be seen. But it looks as overkill to me. Good fix
should prevent the needless events in TreeTable. I file new issue for
it, it will block this issue. Matter this defect is not regression, I
decrease priority to P3. If I'm wrong set priority back to P2.
fixed, TreeTable rev.1.27
In place of clear whole selection are removed only affected paths.
(superior task remains opened, there is more problems with generated
Hmm, this sounds similar to issue 33202 - the problem there is the
output window flashing because a component was added or removed.
I have to revert fix this issue, it leaded to issue 33352. The issue
32567 must be fixed first. (issue 32567 is duplicate this issue de facto)
I was digging through the TTV code the other day, to try to
solve that strange selection problem when the renderer was
changed. It's pretty terrifying *and* heavyweight
(embedding a JTree as a cell renderer and doing strange
tricks to keep the other columns in sync).
FWIW, it could probably be written infinitely more simply
as a JTable with its own handling for expanding/closing/
indenting nodes - similar to the new PropertySheet.
Removing dep on property sheet rewrite - this needs to be
Options dialog based on TreeTableView -> reassigned to Tim.
Changing target milestone to future. It's very unlikely there will be
time to fix this in the 3.6 timeframe; rather it should be put off
until ttv can get the attention it needs.
Note to self: The problem is that the selected node is set on mouse
press. On mouse release, it is set to null and then reset to the the
node that was clicked over.
cvs commit: Examining src/org/openide/explorer/view
Checking in src/org/openide/explorer/view/TreeTable.java;
/cvs/openide/src/org/openide/explorer/view/TreeTable.java,v <-- TreeTable.java
new revision: 1.57; previous revision: 1.56