cornercorner
FeaturesPluginsDocs & SupportCommunityPartners

Bug 175202 - API introduced in issue 151716 doesn't work correctly
: API introduced in issue 151716 doesn't work correctly
Status: RESOLVED FIXED
: mobility
-- Other --
: 6.7
: Macintosh Mac OS X
: P2 (vote)
: TBD
Assigned To:
:
:
:
:
:
: 162137
  Show dependency treegraph
 
Reported: 2009-10-22 13:04 by
Modified: 2009-11-13 12:18 (History)
Issue Type: DEFECT
:


Attachments
Sample code (3.35 KB, text/plain)
2009-10-22 13:18, martin_sladecek
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-10-22 13:04:34
API from issue 151716 allows addition of subnodes to mobility project, but
firing a Change Event doesn't work. The change 
(adding or removing a node) isn't visible.
------- Comment #1 From 2009-10-22 13:18:28 -------
Created an attachment (id=89916) [details]
Sample code
------- Comment #2 From 2009-11-06 09:57:25 -------
Please make this work with Tim next week when he's in or office
------- Comment #3 From 2009-11-12 04:04:10 -------
FYI, I now have a failing test for this problem - looks like the problem
actually may be somewhere in Nodes.  Should have a fix soon.
------- Comment #4 From 2009-11-12 06:09:38 -------
The problem is:  We are actually using a single key, ChildKind.Foreign, in our
Children object, for all nodes from other modules.  When a change event is
fired, we refresh the keys.  But of course, the key list has not really changed
- so the underlying Children reuses its existing Nodes, instead of creating new
ones.

Should be simple enough to fix, just have to decide how.
------- Comment #5 From 2009-11-12 06:43:42 -------
Fixed in main/ changeset 70a0130084fb, regression tests added
------- Comment #6 From 2009-11-12 07:12:52 -------
Fix polished further in 951fcbc170fb to use keys from attached NodeLists
directly, to avoid briefly clearing the keys of the project node
------- Comment #7 From 2009-11-13 12:18:29 -------
x