Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 356298

Summary: Checking keys in visitor of AbstractTreeBox takes too long
Product: z_Archived Reporter: Stephan Merkli <stephan.merkli>
Component: ScoutAssignee: Project Inbox <scout.core-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: Andreas.Hoegger
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Attachments:
Description Flags
Example form the shows the described behaviour none

Description Stephan Merkli CLA 2011-08-31 05:45:00 EDT 
Build Identifier: M20110210-1200

Example form with the two possible methods is attached.

Assumptions: tree with 4 hierarchy levels, about 7000 entries in total.
Goal: All tree nodes that match the filter criterias should be selected.
In the example provided no filter is applied.

Method 1 (slow):
Calling node.setChecked(true) in the visit method

Method 2 (fast):
Caching the keys in the visit method and calling tree.checkKeys(cachedKeys) at the end

Is there a reason that the first method is that slow?
The second method is just a workaround.

Reproducible: Always

Steps to Reproduce:
1. Insert provided form into existing code
3. Start application & open form
2. Click 'select fast' (runs quite fast)
3. Open form again
4. Click 'select normal' (takes quite a long time)
Comment 1 Stephan Merkli CLA 2011-08-31 05:45:55 EDT 
Created attachment 202494 [details]
Example form the shows the described behaviour
Comment 2 Andreas Hoegger CLA 2015-04-14 09:56:52 EDT 
Scout Project clean up.
Bugs matching one of the following criteria will be removed:
- SWT, Swing and HTML(RAP) bugs which are not mandatory for the next release. The future is the new HTML UI.
- Bugs concerning a replaced technology.
- old bugs which got obsolete.
Comment 3 Matthias Zimmermann CLA 2015-07-06 08:24:26 EDT 
bugzilla cleanup for bugs in state WONTFIX, INVALID and WORSFORME and no target milestone.

in case the bug should have been closed by mistake, please reopen the bug and let us know why you think that this bug should not have been closed.