From: Pascal B. <pa...@dy...> - 2000-11-07 17:26:47
|
"should it be posible to say: lyr.add(achild) then blyr.add(achild)?" Hmm, good question, I kinda like the fact of simple calling one method that makes the layer remove it self from the current parent, and be reassigned to another parent.. but it's not very logicall/clean to do :) It would fit into the "open" javascript language, but it could create some nasty problems in larger webapps hmm, not really an answer :-) Pascal Bestebroer pa...@dy... http://www.dynamic-core.net -----Oorspronkelijk bericht----- Van: dyn...@li... [mailto:dyn...@li...]Namens Robert Rainwater Verzonden: dinsdag 7 november 2000 15:37 Aan: mi...@pr... Onderwerp: Re: [Dynapi-Dev] serious bug with new release > In the addChildID() method of the DynLayer class, there is the > "Attempt to add ..." warning alert if you have a layer that has > already been added to the DynAPI.document, and then try to add that > same layer using the addChild() method to another layer. The only place that layers are added to the document.all[] array is in addChildID(). So, if you get an alert, it should mean that the layer has already been attached to another layer or document. So, should it be posible to say: lyr.add(achild) then blyr.add(achild)? \\Robert -- rra...@ya... _______________________________________________ Dynapi-Dev mailing list Dyn...@li... http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
From: Scott A. L. <sc...@sc...> - 2000-11-07 18:27:45
|
That warning was placed in there to prevent multiple DynLayers with identical IDs from being added to the same DynDocument. All DynLayers should have unique IDs, whether assigned manually or generated by the widget code. This is especially important now that we are considering going to only associative arrays in the all[] and children[] collections. I haven't looked at the code in a little while, but getComponent should return a reference to the DynLayer itself, unless you overwrite it in widget code. So before the DynLayer is *created* by assigning it to a parent, the return value would reference the unassigned array. After the DynLayer is assigned, the return value should reference the all[] array of the DynDocument that contains the DynLayer. At least that's what *should* be happening. I'll download the latest package and take a look. scottandrew Pascal Bestebroer wrote: > > "should it > be posible to say: lyr.add(achild) then blyr.add(achild)?" > > Hmm, good question, I kinda like the fact of simple calling > one method that makes the layer remove it self from the current > parent, and be reassigned to another parent.. but it's not very > logicall/clean to do :) > > It would fit into the "open" javascript language, but it could > create some nasty problems in larger webapps > > hmm, not really an answer :-) > > Pascal Bestebroer > pa...@dy... > http://www.dynamic-core.net > > > -----Oorspronkelijk bericht----- > Van: dyn...@li... > [mailto:dyn...@li...]Namens Robert Rainwater > Verzonden: dinsdag 7 november 2000 15:37 > Aan: mi...@pr... > Onderwerp: Re: [Dynapi-Dev] serious bug with new release > > > In the addChildID() method of the DynLayer class, there is the > > "Attempt to add ..." warning alert if you have a layer that has > > already been added to the DynAPI.document, and then try to add that > > same layer using the addChild() method to another layer. > > The only place that layers are added to the document.all[] array is in > addChildID(). So, if you get an alert, it should mean that the layer > has already been attached to another layer or document. So, should it > be posible to say: lyr.add(achild) then blyr.add(achild)? > > \\Robert > -- > rra...@ya... > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
From: Scott A. L. <sc...@sc...> - 2000-11-07 20:14:20
|
I just downloaded the lastest version, and I can't reproduce this bug based on the code in the examples. Mike, do you have a specific example? scottandrew |
From: Scott A. L. <sc...@sc...> - 2000-11-07 23:19:12
|
Ah, I found the problem. There are two errors in the dynlayer.js. In both removeChild and deleteChild, locate this line: DynAPI.removeFromArray(this.dyndoc.allID,child,true) and replace it with this: delete this.dyndoc.allID[child.id] I don't know how the line got changed. Rob, can you fix this in the distribution? It *is* a pretty crippling bug. It seems that removeFromArray is not doing a proper job with associative arrays. However, it should be noted that when using an assoc. array, it's *always* faster and more accurate to simply do "delete array[string]" rather than use removeFromArray. scottandrew |
From: Robert R. <rra...@ya...> - 2000-11-08 00:28:31
|
> DynAPI.removeFromArray(this.dyndoc.allID,child,true) > > and replace it with this: > > delete this.dyndoc.allID[child.id] Yep, I'll remove that. I assumed that the removeFromArray function was working. I also have been working on a site to put at dynapi.sourceforge.net that I will put out there later for people to critique. \\Robert -- rra...@ya... |