Bug 27670 - Editing tasks does not cause re-evaluation of filter
Editing tasks does not cause re-evaluation of filter
Status: CLOSED FIXED
Product: contrib
Classification: Unclassified
Component: Tasklist
3.x
All All
: P4 (vote)
: 4.x
Assigned To: Ondrej Rypacek
tasklist-issues@contrib
: UI
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-09-29 01:04 UTC by Torbjorn Norbye
Modified: 2005-08-12 11:32 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo