Well I finally found time to continue on with my articles on developing Flash components. So if you are interested in getting into the guts of component development I hope I can help in some way with these articles. I’ve almost finished another one so I may post that up tonight too – but I should really eat. So while I grab a bit of dinner check out the latest article in the series :) And hopefully you’ll find them as useful as I find them fun to write.
You’ll find the article here
Thanks for posting this material. One thing that caught my eye is your discussion of variable scope and use use of private designation for properties.
I suspect you are thinking that this is a bit overkill, and if you are using MX 2004 then you’d be right it is overkill. However Flash 8 is very hot on visibility of variables and as all of our declared variables are private our new instance of an empty movieClip cannot directly access them as it is a violation of scope. Therefore we pop a copy of them into our locally scoped variables and all is well and we can use them within our movieClip.
Given that the draw method is part of the class and the class variables are part of the class too, then they shouldn’t be private to the class, just to other classes. Are you implying that the movieclip is accessing these variables in some way.
I haven’t upgraded to Flash 8 yet because it didn’t appear that there was a great deal of new features in regards to ActionScript. Do you know if there is any reference on ActionScript changes with Flash 8?
Something that has often puzzled me is the reason for placing the UIComponent clip into Frame 2. I’ve extended some components by placing the compiled (in contrast to your suggestion of uncompiled) version of a component in Frame 2. And, I didn’t place UIComponent clip in Frame 2. In the end, it worked fairly well and I didn’t see any major loss (e.g., focus, tab order, etc). I have also extended components (e.g, MM button) by taking the fla resources from StandardComponents.fla, subclassing the button.as class, and assigning the new class to the Linkage Properties and the Component Definition dialogs in place of button.as. In that case, UIComponent was part of the resources on Frame 2.
That much said, adding the uncompiled version of the resources works more cleanly. For example, when extending a button, using the compiled button in Frame 2 gave me problems with assigning event listeners to the button. I could assign a listener within the class but later I tried to embed this new button into anther component and I coudn’t listen for click events from within the class of the component that contained the button. In thsi case, I remade the extended button with uncompiled resources and I was able to use the event listener in and out of the component class that contained the button. Clearly there is some scoping issues here but for the life of me I couldn’t figure that one out.
* If we are creating a non UI based component we place an instance of UIObject or UIComponent from our library in this frame*.
* If we are making a generic UI based component then we drag an instance of UIComponent onto the frame
* And finally if we are extending another component we would drag the uncompiled version of the component we are extending from. i.e. that components component clip.
Yes, the with(rs) block of code loses scope of private variables within the class itself – as these are scoped to the class, i.e. our component, but the empty clip we have just created is a sub object within the component clip and as such not directly derived from the class itself just occupying the clomponent clip as a container.
If you remove the locally scoped variables within the method and try to compile it in Flash 8 you’ll see it fails and annoyingly it will do it most of the time silently too.
The reason for the second frame is for nothing more than a storage area to dump all your assets in. Think of it as a holding area to make sure everything the component needs to display and compile correctly is inside the component clip. This is also the reason that the actions frame is only one frame and contains a stop() action.
As all other MM UI Components are extends directly or indirectly from UIComponent eventually you find one of them has it in frame 2. You are right though in some instances you can get away with not including the lower level clips and just using the class import in your component class file
Adding the uncompiled versions leads to less headaches overall – for the most part you can use the compiled SWC versions of the components but a few cause real issues in ‘live preview’ once compiled in. A prime candidate for this is the ComboBox component, this has so many initialization issues it’s unreal. Using the SWC version of this in a component causes it to explode on the screen in live preview, so not very good for positioning it, but behave perfectly fine when exported
Another advantage of the uncompiled components is that this also makes sure that these components compile with the latest version of their own class and any classes they rely on – avoiding an issue that really hits home when combining SWC’s and shared libraries – but that’s another issue
A lot of things do get a bit fuzzy when using the compiled versions in your our components as you’ve found out. I also found out the hard way that compiled isn’t always best :)
I have a question concerning component development. I´m fairly new to this so… Well the problem is when I convert it to swc it doesn´t work, but it works perfectly as a compiled clip. So you have any suggestion to why this is happening? I know it is difficult to explain what’s wrong without knowing more about the component. What I can say is that I have remoting objects implemented in the constructor.