> but you meantion something earlier on this list about
> allowing for DynDocuments
> to be added using the DynAPI.addChild method and then
> allowing for children to
> be added to the dyndocument before creation and thus allowing
> for precreation of
> ALL layers and not just children layers.

no, the idea was that if you add documents to the dynapi object, you can do
a real
freeing of all objects created in the dynapi's onunload, because you have a
children
array containing all documents.

so the dynapi onunload would get this line of code:

for (var i; i<DynAPI.children.length;i++)
DynAPI.children[i].removeAllChildren()

this would be a step towards ensuring all objects are freed and should
support
the memory problem-solving.


other post:

> would it then be worth setting up a dynapi-ext list that is
> used to discuss
> suggested code ADDITIONS.
>
> it would allow for discussion of further expansion of the api
> without bogging
> down the developement list.
>
> this hopefully would also allow for users to make suggestions
> without feeling
> out of their depth in the development list.
>

actually the development list was created for that purpose, the help list is
for users
needing help on using the code.. but in development list all discussions
should be about
the actuall development of the API.  I think that is actually working out
great..with a few exceptions


> I didn't mean to sound so defensive im my previous posts.
> it's 1:30 am here and
> I should get some sleep.

My defensive attitude was not towards you (hope you understand that) Your
one of the
few also popping up with bug fixes and things, so keep it coming..

Pascal Bestebroer ([EMAIL PROTECTED])
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com


_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev

Reply via email to