I am making a project in AS3, but I have come to a point, where I need to branch out, because I want it to publish to 2 places, which each require a bit of different additional code to function properly. So is it possible to achieve that I do not need to make 2 projects and maintain 2 similar projects?
I hope I wrote it clear enough.
Thanks for your responses.
You can do several things, depending on whether you're working in the Flash IDE, Flash Builder, or one of the other tools like IntelliJ.
If you are working in the Flash IDE and/or have a Flash Professional project set up in Flash Builder, you can go into the ActionScript Properties panel and set up a source path that points anywhere (I usually try to keep it relative, but it's up to you).
If you're working without a fla/xfl, then you probably need to look at setting up a library project.
This is a big reaseon for OOP! Write Base Classes and extend them for your Projects as needed.
Also check out Conditional Compilation
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.
In the same way a new XNA project on Visual Studio creates 2 different projects within the same solution (the game it-self, and a content project), I wonder whether MonoDevelop supports a similar behavior.
Thanks in advance!
EDIT
The question isn't from the point of view of a user who wants to add 2 different projects to a same solution, nor the way it's rendered on the tree view, it's about how with a MonoDevelop project template (.xpt.xml and so on) is it possible to create 2 projects at the same time, not just one as it does by default.
Thanks again!
I assume you're asking whether it's possible to have a project that has another project as its child, like XNA content projects are children of XNA projects.
I took a look at the file format, and it looks like contentproj projects are actually just like any other referenced project, but carefully disguised. An XNA Content Project is included in the solution like any other project, and the XNA Project in the solution has a project reference to the XNA Content Project. The only thing that's different is how it's displayed in the solution tree.
So to make it work you'd have to implement the msbuild targets for content projects and xna projects, and write new project types to allow MD to load and save content projects and xna project, then MD's existing load/build/save mechanisms and templating mechanisms would work fine.
To make the solution tree look like it does in VS, you'd have to write several node builder and node builder extensions to override how things are displayed in the solution tree:
hide content projects when displayed directly under a solution
inject the content project under any project that references it
hide any project reference to a content project
The way I understand the MD docs on project templates ( http://monodevelop.com/How_to_extend_the_Project_Model#Create_a_project_template_3 ), looks like you just have to have a couple of different projects declared inside your solution element.
I am fairly new to Flash and AS3.
My questions is do I actually still need to use Flash CS6 to setup the stage and library files.
Or can it all be done from FlashDevelop ?
Thanks
Flash CS6 is an application similar to Photoshop, you generally use it for creating/structuring/positioning graphical resources and then makes it possible to animate these (from keyframe to keyframe) and then access the graphical content from code.
So, the answer is no, you can create a SWF file without Flash, you can embed content to use in AS3-code without flash and you can use flex-components and position them without flash.
But creating any bigger project like that would be pretty unnecessary since you just as well could use some other language or tools for doing that kind of stuff. Tools and languages that were designed to do this specific thing.
Few months ago I switched completely to FD and since today I successfully built everything only in FD. The reason was that I had huge project to publish, and I couldn't compile it in Flash because of memory shortage for JVM compiler. With FD that was not a problem.
So in short, no, you don't need flash any more.
Though maybe there can be some things that you can create quicker and easier way in Flash than in FD (for example: some timeline animation and then publish to SWC to use with FD).
I still have Flash installed, just in case for quick animation jobs.
You need it if you want to create graphic objects to use them later in your code. The alternative is to create everything by code
It depends. If you need to use vector graphics, drawn in Flash, then the easiest way to incorporate them in your project is to use the IDE-based project (http://www.flashdevelop.org/wikidocs/index.php?title=Projects#AS3_Flash_IDE_Project). This isn't the only way, but it's easier than packaging them up and using libraries. In this case you are effectively using FD just as an external AS editor (and it's worth doing it just for this, since it is a much better editor than the one built in to Flash Pro.
If, on the other hand, you are working with objects drawn in code, with text, or with external bitmaps, then no, there's no real need to use CS* at all.
The advantage to OOP is having an environment like Flash for layout. It's been pretty crucial for me as a designer and when implemented correctly with a proper class structure, becomes extremely powerful. It really depends on what you are using as3 for. I find the Flash architecture to be most advantageous in the context of interface design, but for things like games or "static" interactives, sometimes its much more efficient to do everything in code and compile outside of Flash.
I've created a number of skins for various components recently. Some of these were for Spark components and the default behavior of Flash Builder is to take the source code of the original skin and copy into your skin as a starting point.
Normally, I am 90% ok with the original skin, I just want to tweak or add one little thing. It seems to me that duplicating 3 pages of source code to do this is a bad idea. What do I do when I upgrade Flex SDKs? Do I have to go back through the source of all these original skins and (re)compare? This sounds like a disaster.
Is there a way I can create a new skin in MXML that inherits from the old skin? Can I do this via ActionScript?
If you upgrade your Flex SDK I don't think there should be any modification in the skinParts of components. Anyway if there were, you would have a compilation error if one of your implemented skinparts is not of the right type or if you miss a required skinPart. So I wouldn't worry if I were you :)
Another tip would be to use as much as possible CSS styling to avoid this kind of problems.
And no, I don't think you can inherit from a skin and modify its elements (but I'd be glad to be proved wrong).
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.