[Tweener] special properties overwriting each other...

[Zeh Fernando]

> I originally had a glow filter applied to a movieclip.  I was playing 
> around with _tintBrightness and noticed that it tinted my glow also, and 
> it overwrote the alpha setting I had on it.  I also noticed the _color 
> property overwrote my glow color as well.  Is there any way to add a 
> filter such as a glow, and then change the _color or _tintBrightness of 
> the movieclip without changing the glow color?  Or is that pretty much 
> how these properties work in Flash?  Thanks!

That's one of the sad side effects of the way some changes are made. 
Glow and _tingBrightness *should* coexist - they should "notice" the 
different filters and overwrite only the correct instance - but 
sometimes, color changes that are applied using the same filter (say, 
brightness and contrast) will overwrite each other because there's no 
way they'll "understand" each other is there without having a very 
specialized class applied or additional properties that are saved 
somewhere else.

One solution to avoid that kind of behavior is to have an additional 
display container used. That way you can apply one tween to the 
container parent, and the other tween to the inner container. It's odd 
but works.

---8<---

However, my honest opinion, which will probably sound at odds to many 
people, is this: it's counter-productive to use a lot of tweens on image 
processing properties such as brightness, hue and such. While it's nice 
to have those "special properties" there for some quick tweens and 
whatnot, at a certain point having that working as special properties 
tied to a tweening class is kind of bizarre. The best solution is 
building a new displaycontainer class that allows you to change those 
variables directly and every needed variable (like current hue, sat, 
brightness) and color-changing methods are handled internally. THEN you 
could tween it however you wished with whatever you want, or just change 
the values directly without the need to do some third-party static class 
conjuring. A "DesignerContainer" class would be the best solution, and 
that's the kind of stuff I use when I need. I even do so for some 
filters, when I have a "rollover" state that's too complex that I want 
to avoid having a bunch of new tweens done.. I just create a new 
".rolledOver" getter/setter property (that goes from 0 to 1) that 
reapplies the filters when changed. It allows me much better, 
integrated, unified, centralized control over how the thing looks like 
when rolled over.

I know I said I'd write a "DesignerContainer" class in the past, as I've 
used that a number of times, but I haven't had the time to publish 
anything that's as polished and feature-ridden as I'd like. I'm sorry. 
This is being a crazy year.

My point is, when tweening start to become too complex, having 
getter/setter methods for properties, or even using some decorator 
class, is the best way to go. Again, I understand why a "special 
property" with a tween is fast and easy, and that's why they're 
available, but in the long run, having getter/setters doing their trick 
inside the class in any way they please is a lot cleaner.


Zeh