Ive been reading a bit about actionscript 2 and actionscript 3, and there is something I want to ask, does these languages have a main class like in other languages ( C++ C#)...am asking this because I came across alot of code in the net and alot of them seem to not have a main class
Thanks
you're technically wrong about your reply to George. AS2 does not have a main document class. It is POSSIBLE to create a type of pseudo main class, but this STILL requires some hackery by using code on the timeline to prototype the main SWF as a base object and add to it. This is not a document class, but rather a type of extension using flash prototyping. In AS3 you set the main document class explicitly as a compiler argument and that document class BECOMES the main object definition, as opposed to extending the existing one. Lets put it this way, if you asked Adobe if AS2 supported a document class, they would say no. If you stated that you use a document class in AS2 in an interview, they would tell you you're wrong and it would count against you. So the answer to your question is simply "no".
Related
So, I was just wondering if anyone could give me a succinct answer on why exactly it's better to code mostly in an AS3 file as opposed to most on the timeline?
I've heard a lot of people answer questions with a cop-out "don't put so much code in your timeline". I've tried both ways and found some pros and cons on each, but it just seems silly to me for so many people to parrot the general good coding practice techniques.
Another thing about that is that a lot of times I'll be searching for help on coding, and people will give such complicated responses, and half the time I'll use little snippets of code as well as incorporate a small portion into my projects. Also, the AS3 API site also gives waaaay overcomplicated coding examples. Why do people do this? I could figure out some of my issues much more quickly if people just simplified the code examples.
Three good reasons not to put it on the timeline:
Your code will be stuck inside a binary file, not allowing you to use version control nor review changes to it.
You're going to hide code behind menus, making it hard to review in an instance. When it's all in one place you can easily refactor it, and change it.
By putting code on your timeline, you're making your code be dependent on the Animate compiler. (Animate is going to take your code and inject it into your document class using the undocumented function addFrameScript to make things work). The code isn't easy to migrate in this form, if you ever feel the need to re-code in another language.
Please use an IDE when coding. It will help prevent mistakes and even suggest ways to make your code simpler. (To name a few IDEs: FlashDevelop, VSCode, IntelliJ Idea Ultimate (paid).)
To clear up any confusion, writing code in an AS3 file instead of the timeline doesn't mean make things less organized or put code where it doesn't make sense to put it.
What you should be doing is creating a new AS3 file for every MovieClip that you need scripted, then going into the Symbol Properties of your movieclip and selecting Export for ActionScript and set the class name to your AS3 file. The runtime will automatically declare the instances in your file at compile time. What you can do is actually declare them yourself in the file, to have full completion capability in your IDE.
What I like doing is first setting the movieclip to export for actionscript, publishing my project, then opening the compiled swf using Free Flash Decompiler, and copy paste the generated class into a new AS3 file. (You'll want to only copy paste the class and generated instance variables.) Then you can code in your AS3 file with all the symbols contained within the MovieClip already referenced.
It's been about 2 years since I built a component extending the fl.core.UIComponent class, so I figured I would refresh my memory a bit and review the docs. But the docs are not listing all the methods. I know that there are more functions then what is listed on the help page.
If you go to the adobe help for UIComponent page and scroll down to the protected methods I only see the getStyleVaue() method when I know there are more like the "draw" method is one for example.
How can adobe document a class and leave out one of the most important methods.
Is there a filter or something I am missing?
Note: This is fl.core.UIComponent, not the flex one.
You have encountered the wonderful game invented by Adobe called "guess the filter." Make sure you have Flash selected, and the appropriate version of the product.
I was wondering if it could be possible to create a databinding system in pure actionscript without using mx.binding.utils.
At least I would like to know what is the overhead of the databinding code and how exactly the ChangeWatcher knows when a property has been changed.
Thank you!
Check out the Diving in the Flex Data Binding Waters by Michael Labriola: http://www.ruffkutmedia.com/tutorials-diving-in-the-data-binding-waters-by-michael-labriola.htm (video) - slideshare here: http://www.slideshare.net/michael.labriola/diving-in-the-flex-data-binding-waters-presentation
There's a lot of work that goes on behind the scenes when you bind data, but he gives a really good explanation of how it works. It's a bit awkward to create something that works automatically unless you're passing through a "compile" phase where you add code.
You can also check out the as3 commons byecode project: http://www.as3commons.org/as3-commons-bytecode/index.html which should let you add code at runtime
The flex compiler actually compiles your MXML/AS3 to pure AS3 before it compiles it all to bytecode anyway. So at some stage in the compile process, data-binding is actually being implemented with ActionScript.
The problem is that Flex adds a bit of syntax specifically for data-binding. There is nothing stopping you from creating a data-binding system in AS3, but there are limitations, such as you would have to do it in an AS3 way.
I'm working on a project in Flash CS4/AS3 and I have a document class set up but I am wondering about using that, as opposed to frame-based scripting. Most of what I have seen so far deals with how to create them, but doesn't offer much about why or when to use them.
I know I can also pull in other classes beyond the document class but, again, why and when?
Could I get some input from you fine people out there on usage/best practice, etc?
Thanks
If this is just a simple demo or a movie, you can use the time line.
But if you're going to make a program, with classes, you should have a document class.
A document class is the main class of your programs. it's actually your initializer of all the program's processes and components, and it's simply more proper and similar to other programming languages.
Plus, it's in a different file, and it is easier to edit it this way.
Also, your doc-class will be a class and not just code in the air.. it also has auto-complete in CS5.
I've been writing in actionscript 3 using flex builder 3 for a couple of weeks now and never encountered the need to use anything like MXML. I code all layout and design in pure actionscript.
I am not sure why, but many people immediately expect me to have written a lot of MXML when I say that I'm using flex builder.
Is MXML really recommended? If so, why did I never encounter the need for it yet?
As MXML is compiled to ActionScript while building, there may be no need for MXML - everything can be coded in AS3.
However, I find that MXML is quicker to use in some scenarios - for example, composite components of the UI in an application.
If a composite component is a library-type component (a new type of generic widget - whether based on an existing control or completely custom), I use AS3 as I get finer control. The code for such controls will not change much over time, once a stable release is made.
If a composite component is a part of an application's UI which is more likely to change over time due to user-driven changes to the UI (e.g. application configuration panels) then MXML allows faster iterative development. This is the kind of change where you have to move controls around, change styling etc. in response to user or marketing feedback, or business-driven changes over time.