I just use whatever I can get to work. I'm happy just using flex, and when I use some old flash its only because I don't know any better. The ball class is from the foundation action script 3 animation book and there is no import mx.core.UIComponent; in thier example.
When you say: If you're new to Flex, I suggest beginning with complete Flex examples that use standard Flex components and postponing trying to use Sprites-based classes. I'd do that if I could figure out how. The "live docs" are not good for learning form because the examples are either not complete or are way too complete with too many distracting bells and whistles. They need to start with basic building blocks but they don't seem to understand the concept. It just blows my mind how bad the documentation is. . Can you suggest a book ? Gordon Smith wrote: > > Built in to the Flash Player are low-level flash.* classes such as > Sprite. The Flex framework libraries contains higher-level mx.* > classes such as UIComponent, Button, Container, VBox, etc. which add > many capabilities beyond those in the Player. > > The Flex framework was designed with the assumption that most > developers would be delighted with the greater capabilities of > the high-level classes and not have much interest in the low-level > ones, which are primitive by comparison. In hindsight, this was > wrongheaded. Many people like you want to mix the two -- generally > because the low-level classes can have greater performance or smaller > code size, or because you're bringing over code from the > Flash-not-Flex world -- and it isn't as easy as it should be to mix > them. I hope we can do better in a future release. > > You write AS3 code to use both flash.* and mx.* classes, and, once you > understand a few rules, you can use both sets of classes in a Flex > application. But it isn't completely trivial, so it's dangerous to > just take a simple Sprite-based class and expect it to "just work" in > Flex. > > The problem you're running into here is that Flex Containers such as > VBox assume that their children are high-level UIComponents rather > than just low-level Sprites. One reason is that containers do > automatic layout management, which requires code in the children to > report how big the child wants to be, etc. > > So currently you have to work around this assumption by doing things > like creating an intermediate UIComponent to parent the Sprite or > adding the Sprite to the Container as a "raw" child (see the > rawChildren property). > > If you're new to Flex, I suggest beginning with complete Flex examples > that use standard Flex components and postponing trying to use > Sprites-based classes. You'll make more progress, gain confidence, and > then be in a better position to understand how to take advantage of > Sprites later. >
