0

Suppose I have a 3-frame MovieClip with a box (instance name "box"). Each frame applies a different blur to the box, so that it's a little blurred on frame 1, a little more blurred on frame 2, and very blurred on frame 3.

I can call "gotoAndStop" on any of the three frames, and the correct blur will be applied, and I can do this as many times as I want without problems.

HOWEVER, if at any point I change the width of the box for example "box.width = 100", then suddenly when I call "gotoAndStop" the keyframe information is no longer applied and the box's blur does not change. If I add a position change as well on frame 2, the same behavior arises... the position change works on gotoAndStop until I change the width of the box, then it no longer moves when I go to and from that frame.

Why does Flash stop applying keyframe information like this when I change a property like "width" on a keyframed object?

Triynko
  • 18,766
  • 21
  • 107
  • 173
  • how do you add blur, how many keyframes are there, on which layers, where is the code? I had problems like this with timeline animations and didnt realize everytime you create a keyframe on the layer where box lies it will become a new instance... or was it like everytime you add keyframes on the script layer you cannot access the old names something like this... timeline logic is abit wierd^^ – Sidrich2009 May 03 '12 at 22:11
  • The blur is added to the box in the IDE (no code) on each of 3 keyframes on a single layer, and the code that calls "gotoAndStop" is in a TimerEvent handler. There is no problem accessing the instance at any point. In fact, I'm very familiar with the Flash Player's treatment and manipulation of timeline instances under virtually every possible circumstance (see my post/response: http://stackoverflow.com/a/5265776/88409), so that's not the problem. The problem is simply that an otherwise perfectly functional timeline simply stops updating "box" if you change box's width. – Triynko May 04 '12 at 00:09
  • You can even add other layers, other objects on the same layer, etc. etc. and keep calling gotoAndStop to switch between frames. Every single object continues to be updated normally, EXCEPT box (after you modify its width). It's not even the value that matters, because setting "box.width = box.width;" causes it too. If I modify "width", "x", "scaleX", etc. on any object at all, that object will also stop being updated while everything else updates normally as the frame changes. Flash Player's internally generated timeline instance code must watch properties for changes and abort keyframes. – Triynko May 04 '12 at 00:13
  • Seriously, it's as though if you touch the object at all with ActionScript to modify it in any way, Flash outright aborts any further keyframing of the object, which means you can either keyframe an object's motion or manipulate it with ActionScript, but never both. Total technology fail, IMO, and 100% reproducible. I posted it as an "incorrectly functioning" bug at Adobe's bug management system. – Triynko May 04 '12 at 00:19
  • There are sometimes problems with one method, but you can go for alternatives. Like, instead of setting blur via IDE, you may add a code to blur the movieclip on that particular frame. So there would be 3 frames each having it's own blurring code. Have u tried this ? – Vishwas May 04 '12 at 04:03
  • My SkinnedButton class has a "skin" clip for visuals and a "surface" clip that receives mouse events and determines the shape of the button. The "skin" clip's point is to have labeled frames so that using the IDE to create buttons would be visual and easy. The class supports labels of default, rollover, rolloverselected, selected, rollout, press, release, releaseoutside, trackover, trackout, dragover, dragout, and dragdrop. All frames are optional but default, because each frame has a series of logical fallbacks defined such as releaseoutside > rollout > default. – Triynko May 04 '12 at 17:39
  • But yes, I have tried what you're suggesting. Because of the limitations of this keyframing problem, I created a SkinnedButtonSkin class to use in place of the regular skin clip, which overrides gotoAndStop and swaps in named instances of clips instead of actually calling the default implementation of gotoAndStop. This allows me to avoid keyframes altogether, and utilize my docking system logic to layout individual button states, but it's no where near as convenient or simple as the IDE keyframing, where I can have keyframes span multiple frames or click through them to see state transitions. – Triynko May 04 '12 at 17:44
  • I use my own docking framework where everything extends from "GUIControl", so what I'd have to do is create a "GUIControlInsulator" wrapper for each frame's content and apply position keys to that. GUIControlInsulator would extend MovieClip and would never be modified by code, which would avoid triggering the player to abort keyframing it. The insulator would then require a single GUIControl child to reinstate a dockable environment at that level, and the GUIControl's docking routines would need altered to recognize GUIControlInsulators and reach inside to resize the lone GUIControl container. – Triynko May 04 '12 at 18:19
  • The bottom line is that if you touch the "width" or any other potentially keyed property of a keyframed object with code... the player immediately aborts all subsequent keyframing of that object. – Triynko May 04 '12 at 18:25

0 Answers0