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 27670

Summary: Editing tasks does not cause re-evaluation of filter
Product: contrib Reporter: Torbjorn Norbye <tor>
Component: TasklistAssignee: Ondrej Rypacek <rypacek>
Status: CLOSED FIXED    
Severity: blocker Keywords: UI
Priority: P4    
Version: 3.x   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:

Description Torbjorn Norbye 2002-09-29 01:04:57 UTC
If a filter is in effect, and you edit one of the
properties of a task such that it no longer matches
the filter, the task is not removed. It probably
should
be.
Comment 1 Tim Lebedkov 2002-12-20 11:18:08 UTC
I changed some things in TaskListener in order to solve this.
But get following exception each time I edit a task.

java.lang.IllegalArgumentException: An explored context (B) must be
within the root context (Summary).
	at
org.openide.explorer.ExplorerManager.setExploredContextAndSelection(ExplorerManager.java:299)
	at
org.openide.explorer.view.BeanTreeView.selectionChanged(BeanTreeView.java:86)
	at
org.openide.explorer.view.TreeView.callSelectionChanged(TreeView.java:613)
	at
org.openide.explorer.view.TreeView$TreePropertyListener.run(TreeView.java:874)
	at org.openide.util.Mutex.postRequest(Mutex.java:860)
	at org.openide.util.Mutex.postReadRequest(Mutex.java:349)
	at
org.openide.explorer.view.TreeView$TreePropertyListener.valueChanged(TreeView.java:844)
	at
javax.swing.tree.DefaultTreeSelectionModel.fireValueChanged(DefaultTreeSelectionModel.java:629)
	at
javax.swing.tree.DefaultTreeSelectionModel.notifyPathChange(DefaultTreeSelectionModel.java:1076)
	at
javax.swing.tree.DefaultTreeSelectionModel.setSelectionPaths(DefaultTreeSelectionModel.java:287)
	at javax.swing.JTree.setSelectionPaths(JTree.java:1194)
	at
org.openide.explorer.view.TreeTableModelAdapter$Listener.updateNodes(TreeTableModelAdapter.java:174)
[catch] at
org.openide.explorer.view.TreeTableModelAdapter$Listener.run(TreeTableModelAdapter.java:163)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:448)
	at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197)
	at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:99)
Comment 2 Torbjorn Norbye 2002-12-20 17:25:44 UTC
Are you trying to set the node selection, or change the root node? If
changing the node selection, you have to be careful that the node
you're selecting is actually a descendant of the root node in effect.
This gets complicated when filter nodes are in use.
TaskNode.find(Node, Task) can help you (and to get the root to use
during the find, use view.getExplorerManager().getExploredContext(),
NOT view.getRootNode() - since that always returns the "base" root,
not the filtered one if one is in effect.

If you're trying to change the root itself, make sure that no nodes
are already selected. There's an example of this (workaround) in
TaskListView.setFilter: the first thing it does is remove the
selection (by setting the selection to an empty array) and THEN it
calls setRoot() to change the root node being explored.

By the way, your commit commented out javahelp related classpath stuff
in build.xml.  That was not intentional, right?  If you're having
problems building with that code in, your nbbuild module is out of date.
Comment 3 Tim Lebedkov 2003-01-01 14:50:49 UTC
The only problem now is:
If you change a task in the filtered view the whole tree of nodes will
be recreated and the tree will be collapsed. Is there a way to remove
children from nodes to prevent this?
Comment 4 _ pkuzel 2004-03-05 17:34:54 UTC
It colapses only if there is empty intersection between old and new 
Childen.Keys sets. 
Comment 5 _ pkuzel 2004-07-26 17:41:52 UTC
I doubt that a usertask should disappear as result of property
editing. But I can imagine task disappearing while moving (gesture
that I'm done with it) to next task i.e. leaving current 'record'.
Comment 6 Tim Lebedkov 2004-08-31 18:21:12 UTC
already fixed.
If a user marks for example a task as completed and the current filter
does not accept those tasks the task will disappear from the list.
Comment 7 Tim Lebedkov 2005-08-12 11:32:34 UTC
NB 4.1 is out