I'm looking for technical documentation on how 开发者_C百科Flash manages object instances with the same name across key frames.
So far, I've noticed that when the play head moves to another frame, if an object with the same name has the same type, then the instance is preserved along with its dynamically set properties.
On the other hand, as soon as the play head goes to a frame where the named instance is a different type, then it creates a new instance of the new type (with the original name), and the original instance of the old type is permanently discarded and all dynamically set properties on the named instance are lost (because it's a new instance).
If you go back to the original frame, it does not restore the original instance, but treats it as yet another change, and constructs a new instance again. Is there any documentation that describes this behavior?
Similar question on "continuity of timeline instances": http://www.kirupa.com/forum/showthread.php?t=316612 I too was surprised that properties carry over. It seems like a run-time feature, where Flash will create a new instance, only if the (instance name / symbol type) pair changes in the next key frame (i.e. if named instance "obj" refers to a "ball" in both keyframes, then it will remain the same instance; but if "obj" refers to a "square" in the next keyframe, then a new instance of "square" will be created). It makes sense, but is this behavior guaranteed?
This is too long to post in the comments, but I discovered various other behaviors using frame scripts.
So far, an object with the same instance name on different key frames causes new instances to be created only when we have:
- different symbol type or
- same symbol type and different layer
- navigate to an intermediate key frame that does not contain the object
In other words, as long as instance name, symbol type, and layer the object is on remains the same from frame to frame, and each frame contains the named instance, then filters and transforms alone won't cause new instances to be created.
Things get interesting when ActionScript is involved.
---If you REMOVE THE OBJECT WITH A SCRIPT:---
Same instance name, same symbol type, same layer:
- If you remove the object with removeChild on frame 1, then on frame 2 no new object is created. In fact, the old object still exists, but it's not visible and NONE of the transforms from frame 2 are applied (i.e. the object retains its original size, filters, etc.).
- If you remove the object with removeChild on frame 1, and then immediately re-add the object, then it persists and is visible in frame 2, but still NONE of the transforms from frame 2 are applied (i.e. the object retains its original size, filters, etc.).
Same instance name, same symbol type, different layer:
If you remove the object, a new one is created on the second frame as expected, since it was on a different layer. Being on a differnet layer is almost a guarantee that a new object will be created as you will see from the next statement...
If you remove the object then immediately re-add it (removeChild(obj); addChild(obj);), then you end up with a DUPLICATE, because the new instance with new transforms on frame 2 is still created AND the original object remains (whereas if you had not removed/added it, the key frame change would have destroyed it).
Summary
Across key frames, the only things that will trigger the creation of a new object with the same instance name is if the object has a different symbol type or is on a different layer, or you visit a key frame that does not contain the object and then return to one that does. Nothing else will cause a new instance to be created. Removing the object with ActionScript (even if you immediately re-add it), will cause the player to NOT apply new key frame transformations to the object, but in and of itself will not trigger the creation of a new instance.
I have never seen this officially documented since I started with AS in Flash 5.
Your observations match mine, but another case is "same name, same type, new keyframe, different layer" which reinitializes the object in AVM1. I am not sure what AVM2 does, since I really try to avoid these situations, but this can be a decent way to get a MC to reinit on the timeline if you need to.
It isn't a documented behavior but your observations are correct. However, there's a potential snag that can happen to you if your two objects that share the same instance name are of incompatible types in that Flash might try to coerce the second (or all following) into "being" or trying to act like the first one it found. This may have been particular to fp9 but the behavior was 'scarring' enough to advise that you should NEVER have two different objects share the same instance name on the same timeline.
You might want to look at This blog entry on timelines and instance names that I wrote about the subject for a little more illumination.
One other thing that I may or may not have touched on adequately though, is that this behavior can also wreak massive havoc if you've nested timeline sounds in any movieclip that might be "skimmed" over if you use gotoAndStop/Play to "skip" around a timeline.
精彩评论