So Michael and I exchanged a few emails offlist and we diagnosed the
problem and I've got some workarounds for those people encountering the
same issue.
The problem was that Michael would make changes in his model that would
inadvertently send a RESET type of collectionChange event. The Tree
responds to a RESET collectionChange event by resetting scroll positions
and closing all open nodes. This was not desirable.
What was happening was that the Tree's dataProvider property was being
bound to a data model, a la: <mx:Tree id="myTree" dataProvider="{col}"
/>. When a binding expression is used, watchers are created that watch
the model (col) for changes. Certain types of changes cause the binding
to update and actually re-set the dataProvider property (to the same
value it was before). Re-setting a list control's dataProvider property
will cause a RESET type of collectionChange event, and this was the
source of all the problems. By having the Tree depend on binding to set
the dataProvider, inadvertent RESET events were being emitted.
The easiest workaround for this is to set the dataProvider
programmatically instead of relying on binding (ie: in a script block,
do: myTree.dataProvider = col). In some cases, this may not be a
sufficient workaround. Another more detailed option is to actually
prevent the RESET from being dispatched in cases where the Tree
dataProvider is being set to the same thing it was before. To do this,
one would override the Tree's dataProvider setter to add an identity
check to verify that the value being passed in to the dataProvider is
something new. IE:
override public function set dataProvider(value:Object):void
{
if (_rootModel == value)
return;
else super.dataProvider = value;
}
Now, the catch with that is if someone has a Tree bound to a collection
and they change the list the collection is wrapping (via changing the
list property), the overridden dataProvider setter will not process that
change because the identity check will return true.
Given all of this, one of the above workarounds can be utilized for
anyone running into the inadvertent RESET issue.
-deepa
________________________________
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of Deepa Subramaniam
Sent: Monday, December 11, 2006 3:40 PM
To: [email protected]
Subject: RE: [flexcomponents] XML :: Tree :: XMLChangeWatcher
Yes, an example would help.
>From what you've described, it sounds like your modified setToggled()
code is causing the RESET and that is the source of your problem. Take a
look at the other methods in DefaultDataDescriptor that update
attributes on nodes (setToggled(), setEnabled()) and follow that pattern
and you should be ok.
-deepa
________________________________
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of Alex Harui
Sent: Monday, December 11, 2006 12:48 PM
To: [email protected]
Subject: RE: [flexcomponents] XML :: Tree :: XMLChangeWatcher
Can you make a mini-example for us to debug?
________________________________
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael Schmalle
Sent: Monday, December 11, 2006 11:59 AM
To: [email protected]
Subject: Re: [flexcomponents] XML :: Tree :: XMLChangeWatcher
Oh yeah,
When I have the Tree scrolled and select a checkbutton and toggle it;
This is a trace fromt he tree's collectionChangeHandler() override
''
collectionChangeHandler() update
collectionChangeHandler() update
collectionChangeHandler() update
collectionChangeHandler() update
collectionChangeHandler() reset
''
As you can see, right at the end a reset event.kind is comming through
and that is what is resetting the tree.
Peace, Mike
On 12/11/06, Michael Schmalle <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > wrote:
Hi Deepa,
I'm using the DefualtDataDescriptor as the super class but, I have a
midified version of the setToggled() method.
var field:String = tree.toggledField;
if (node is XML ||
node is XMLList)
{
try
{
if (field.search("@") != -1)
{
node[field] = value;
}
else
{
node["@" + field] = value;
}
//trace("NODE", [EMAIL PROTECTED], field)
}
catch (e:TypeError)
{
//trace(e)
}
}
It's actually this line;
node[field] = value;
that goes to the XMLChangeWatcher.
Once it is in the change watcher and update is called and then a reset
is called.
In the change watcher, it hits the attributeAdded.
path;
initializeXMLForNotification()
IXMLNotifiable(notifiable).xmlNotification(currentTarget, ty, tar,
value, detail);
currentTarget : the node the descriptor changed
ty attributeAdded
tar node
value toggled
detail true
xmlNotification()
case 'attributeAdded'
itemUpdated()
itemUpdateHandler(event);
listChangeHandler()
You know, as I am writting this I am running the debugger. I can see the
update everywhere. It goes on forever. Then I step throught to the end
and it's the last thing that happens. I can't find it right now but,
right at the end it resets the tree.
It definitly is being spawned by this
-> node[field] = value;
Peace, Mike
On 12/11/06, Deepa Subramaniam < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > wrote:
Hi Michael -
Whenever an item is updated in the model, the Tree should receive an
UPDATE type of collectionChange event, not a RESET. Have/Can you narrow
down which call is causing the RESET to be emitted? My attempts to add
an attribute to a data item in the model via the descriptor or through
the model itself always produce an UPDATE type of collectionChange
event.
Incidentally, we use the setToggled() method in DefaultDataDescriptor
for menu-based controls. I'm assuming you're adding a similarly named
attribute to your Tree's model to indicate to the CheckBox whether it
should be selected or not?
-deepa
________________________________
From: [email protected]
<mailto:[email protected]> [mailto:flexcompone
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ] On Behalf Of Michael
Schmalle
Sent: Saturday, December 09, 2006 8:35 AM
To: [email protected]
<mailto:[email protected]>
Subject: [flexcomponents] XML :: Tree :: XMLChangeWatcher
Hi,
I have a little problem here.
I have a check box tree that works fine most of the time. I have run
into a bug that I didn't have before.
I have debugged it using the debugger and found the 'problem'. When you
assign an XML dataProvider, I use a dataDescriptor that sets an @toggled
attribute on the model.
The problem is, the XMLChangeNotifier sends an attributeChanged event
and eventually down the line, the Tree gets a CollectionChange event
that is a 'reset' right at the end of a toggle on the check box.
The problem is, if the Tree is scrolled, it resets the scroll position
to 0 every time becasue of the reset event.
I have tried doing a hac blobk during toggle select but, it ends up
messing the view of the Tree.
How can I fix this?
Peace, Mike
--
Teoti Graphix
http://www.teotigraphix.com <http://www.teotigraphix.com>
Blog - Flex2Components
http://www.flex2components.com <http://www.flex2components.com>
You can find more by solving the problem then by 'asking the question'.
--
Teoti Graphix
http://www.teotigraphix.com <http://www.teotigraphix.com>
Blog - Flex2Components
http://www.flex2components.com <http://www.flex2components.com>
You can find more by solving the problem then by 'asking the question'.
--
Teoti Graphix
http://www.teotigraphix.com <http://www.teotigraphix.com>
Blog - Flex2Components
http://www.flex2components.com <http://www.flex2components.com>
You can find more by solving the problem then by 'asking the question'.
