Today I wrote a filter tween component. In it self it wasn’t very hard, but ActionScript didn’t help very much. I never cease to be amazed over how bad the ActionScript API:s are (I have a feeling this is how most of my posts are going to start).
Take the filters property of the MovieClip class, you would expect the filter API, which came with Flash 8, to be modern and object oriented, but no. It’s a property, it’s an array that I have to manage by myself, and what’s more: it actually returns another array from the one I set.
That’s actually not uncommon in ActionScript, other properties work the same, for example the scrollRect property of MovieClip (also a Flash 8 feature). What I don’t understand is why. Firstly, it’s confusing, and secondly it makes the properties harder to use, since direct manipulation is not possible, for example.
Today’s problem with the filters property was this: I want to tween a property of a filter that has been applied to a movie clip. To change a filter, I have to get the filters property, save it in a temporary array, get the filter from the array, change the filter, and then set the array to the filters property of my movie clip.
That’s fine, if there was any way of knowing which filter was which in the filters array. If there are more than one filter, there is no way of knowing which filter is the one I want to tween. It doesn’t matter if I have a reference to the filter, since it seems as if it’s been copied (a search with == in the array yields nothing).
In the end, I had two options: either accept that for filter tweens to work there can only be one filter applied to the movie clip, or require that the code calling the tween sends the index of the filter to tween, instead of the filter itself. An ugly and non-OO solution, which could easily have been avoided with a little better software engineering on Macromedia’s part.
In a better world, I would only have had to change the filter itself to change the effect on the movie clip. That would have been a proper solution.