What do you mean Robert?? Is THAT good news?? LOL
Obviously it is not handled by the DynAPI, because
the deleteChild function instead of hiding the layer
does a "delete c" as we know already.
If what you say were true, then THAT shouldn't be happening.
simple!
Correct me if I am wrong, but peo
All of this is already handled by the DynAPI. If you look at the code
you will see that when you remove a layer in NS 4 is hides the layes
and puts it in a recycled array so that it can be used later. I'm not
sure what the bad news is. NS4 has always been this way.
--
Robert Rainwater
On 6
BAD NEWS PEOPLE - Unless what I have found out is not true (I wish)!
I have also been plagued by the deleteChild/deleteFromParent syndrome,
on several occasions and had to resort to work-arounds.
Tonight I came accross it again writting a dynamic explorer-like tree
structure.
I really need to DEL
The answer to your second question is easy. The browser gets a time slice.
If the browser has to update the screen it takes part of that slice and
spends it on updating the screen and therfore less time is spent on
execution of JS code.
8an
___
Dynapi-
> ey guys, I looked at DynAPI today and saw that it wasn't xHTML compliant,
> so I made a small file that documents incompatibilities with xHTML on the
> 2.53 release.
Nice work! I'd vote for adopting most of the changes.
> xHTML Analysis of DynAPI v2.53
> Author: Anarchos
> Date: 6-15-01
> E-m
> I will fix the bug soon. However, your fix does not delete the
> object, but the array element.
As I understand it, delete doesn't delete an object but cuts the
variable (or the attribute) and therefore the reference out of the
namescape.
> I believe this would cause a memory
> problems.
Th
