i have problem making quiz in as3, this is the code in AS2 for scoring,
i wonder how the code is in AS3, can anyone help me, thanks a lot.. :)
{
salah += 1;
if (jumlah_frame>=0) {
jumlah_frame--;
gotoAndStop(array_frame[jumlah_frame]);
}
if (jumlah_frame<0) {
gotoAndStop(12);
}
}
That is the translation for AS3.
My guess is that you didn't even try to compile this in AS3. There may be other bits of code surrounding this that would break the file as a whole or something, and the greater context established by the surrounding code may even break these lines; but these lines, without knowing how the variables were declared or the functions were defined, are perfectly valid syntax.
When you try to port something from one language to another, you really need to show some more effort to get it done on your own. If you don't know the language you're trying to port it to, then that's a VERY good time to learn, and the attempt to translate the code will be a very good programming excercise to help you learn that new language. But you really don't ever want to ask people on a forum like this to translate code from one language to another, unless you've put forth some real effort and are running into much more complicated, technical issues than anything in these lines of code.
I'm not trying to be mean, but you do need to be aware of this sort of thing in general, not just with regard to questions about porting and translation.
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.
First off I apologize for the slightly vague question.
I'm a self-taught coder and the more I work, the more I find myself wanting to invest in the whole process (and God knows there is room for improvement).
I'm looking for very "basic" material (books recommendation if you can!) about things like how to structure code and comments to make things clear, how to structure a project directory (How far should I divide my stuff into packages? How to properly name classes, subclasses, make it all understandable and clear?), this kind of stuff. Not the actual how make things work, but rather how to make things clean, understandable and well structured.
I've been reading a lot on design patterns, good software design and things like that, but there is this "gap" in my knowledge where I can think of a good solution to my problems, but the execution itself is pretty messy and ugly.
I've always worked solo, and chances are I will soon be working with other coders on my projects. Right now I sometimes have trouble understanding my own code, so there is no way others could dive in and help me.
I'm coding in AS 3.0, should anyone wonder.
Thank you very much :)
Depending on how new you are to coding, I'd recommend looking into why 'encapsulation' makes sense.
When I was new to object oriented programming I couldn't understand the appeal of encapsulation, but now I see how it really can help keep your code 'clean' - and I strongly suspect it's fundamental to a lot of other object oriented concepts; Design patterns, avoiding 'tight coupling', composition, code reuse and so on.
Here's the wiki info on encapsulation...
http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)
..but here's my summary:
I've heard the analogy of a car used: The user doesn't need to know HOW the engine works; they just need to know that, when they turn the key, the engine WORKS. Encapsulation keeps the implementation of a class's methods secret. The methods themselves are public (to be accessible outside the class) but properties are private.
By making properties private and limiting the number of public-facing methods in your classes you can have your classes operate as independently as possible. It also means you can totally change HOW a method is implemented inside a class (so long as it retains the same name and argument signature) without anyone OUTSIDE of that class needing to know anything about it. Even if that 'anyone' is YOU it can still really speed up development because you're not having to track down multiple references to public variables of the class throughout your code.
So AIM to have your classes perform one function; Think about if a method would, in fact, be better 'hidden away' in another class. Even if you have multiple objects instantiated 'inside' another, your code will be much more clean and you can be more sure about WHERE that specific piece of code you're searching for is - if a class mostly has one function, it's easier to remember what it does.
Other than that, I'd also recommend using only shallow inheritance; Having a complex hierarchy of classes and subclasses can lead to objects that need to inherit from more than one class. Look into 'composition' and interfaces too. (Interfaces are kind of AS3's solution to not having multiple inheritance).
I am just getting into object oriented programming, and I was wondering, is it okay to put some code on the timeline, like stop(); and mouseclick events for moving frames, or should all this be on separate files also? If they do belong in other files, how would I go about doing that?
MPO is that you should learn the tool as the tool. I think that the timeline is the very best part of Flash, and if you throw that away, you are making your life harder for no good reason. I think all tools have a "code way" and "some other" way to accomplish what they do, and the default of most developers is to assume that the code way demonstrates your skillz and that "the other way" is so obviously easy that it's not worth your time to learn it.
IME, nothing could be further from the truth. I have learned these "other ways" in several tools/language, and you pretty much always get more power and productivity out of knowing both, at the risk of having a significant fraction of your fellow developers looking down their noses at you because they assume that if you're really good at "the other way" that you are doing it because you can't code. For this reason, there are very few developers who truly understand the full depth and subtlety of the timeline, and there are almost none who will talk about how to do this well.
I actually develop scalable enterprise-level Flash applications using the timeline for clients whose stores you've almost certainly been in within the past couple of days, so I do have a fair amount of experience in this area. My rule of thumb is that stop() is ok if it is unimportant to the overall functioning of the program (it's a visual thing only). However, it gets tedious after a while to keep adding it, so when you get to where you're not under deadline pressure, you'll probably replace that at some point with a Class that uses addFrameScript to do the stop().
The best use for timeline code is when you need to synchronize things (for example, with a streaming sound, which has absolutely zero Actionscript handles to get hold of it). Generate a bubbling event at the precise point where the narrator is saying "click the thingamajig" and you've animated the cursor over the thingamajig. Then, in the AS code that controls the parent of the timeline with the streaming sound (or grandparent, or whatever--somewhere positioned to catch the event), you'd put the thingamjig into the toggled state (for example by changing the data model the thingamajig is responsible for displaying).
Very, very occasionally, I will use timeline code to do something more significant. One example is that a swf compiled by Flash Builder knows what color its stage is, but one compiled by Flash Pro does not, without reading the bytes of the swf. I have a Class that fades a graphic in that can only get the real stage color sometimes, depending on how it was compiled (I'm not goint through the mess of reading the bytes--that's frankly ridiculous). So, I just assume we're fading in from white or something close to it (which we are most of the time). For the rare case where it's not, I've noted in the ASDOCs for the Class that it's ok to just populate the color variable from the timeline rather than worry about how to get it in there through dependency injection. I view this as kind of a poor man's version of the Flash Components properties panel.
Hope that points you in the right direction :).
I think it depends on what you mean by is it okay. (no I am not Bill Clinton)
You'll be hard pressed to get a positive response on this as most of the community on SO are developers and generally are not huge fans of using the Flash IDE/Timeline coding.
That being said, I try to always remain open minded and do realize there's a place for the Flash IDE in creating motion graphics quickly, etc. There's nothing that says you should not code in the timeline, if you absolutely shouldn't do it, they wouldn't have made it possible.
The problem I think arises when you start working with other developers and have to figure out where they buried some code on the timeline within some movieclip that is affecting things. For small projects this isn't really an issue, getting into larger teams (3-5 devs at a time, maybe more) then being able to work independently and collaboratively becomes a challenge.
One last point since you say you're just learning OOP. AS3 is a great language, tons of fun, lots of features provided by the run-time so you can just jump past some of the nitty gritty in C/C++ etc. But the concept of the Timeline is unique to AS3. So if you learn to do everything based on the Timeline, then moving to say C++ or Java or C# or any other OOP will likely be that much more difficult. For now I wouldn't stress about this since you're just getting rolling, but just something to keep in your mind as you move forward.
Edit (response to Ms. Blankenship's good answer and comments from Mr. Mear)
I think there is some arrogance on the side of developers. I can speak for myself in saying I've generally not been a fan of WYSIWYG editors (except when I try to build them, then they're okay :).
A couple of reasons:
They have in my past experience been terrible (take Word or DreamWeaver's code output as examples, try to work on a site some mom and pop threw together in one of those apps and you'll start to hate it too).
If someone was able to get this completely right it would invalidate a lot of knowledge I've built up (so it gets me into a defensive stance, not an objectively valid reason, I know).
Working with bigger teams finding code is key + the code editor is bad (compared with any of the alternatives, Flash Builder [my tool of choice], FDT, FlashDevelop, IntelliJ [my friends' tool of choice]).
Coming from a OOP background that doesn't include anything similar to the Timeline and potentially moving back to those technologies. You have the choice to be great at 1 thing or good at 5 things what do you choose? (I'm vastly over simplifying but hopefully you get the gist). I learned to use Eclipse writing Java, I can use the same tool to write C++, C, PHP, etc. This isn't to say I actually always use Eclipse for everything (lately been using SublimeText a fair amount), but I like that it's always an option. As an aside I'm not an Eclipse "Pure Blood", I started off early on playing with Flash IDE and HTML/JS in Notepad, used Visual Studio for a bit, eventually got pushed into Eclipse but have taken a liking to it for the all in oneness.
Ultimately there are too many factors in this open ended situation to say that one solution is the end all be all. To explain with an analogy, if you were to build a birdhouse a hammer, some nails, and some wood are probably all you need. If instead you want to build your own human house you're going to need some different tools (probably including a hammer, some nails and wood).
Also a related SO post (re-hashes many of the same points):
Why not use Interface Builder
I'm new to AS3 and have been putting my code on the timeline and everything seems to be working fine (apart from the usual issues learning a language).
What I'm wondering is why so many threads say don't put code on the timeline? Can someone recommend some resources for me to get a good birdseye view of best practice programming in AS3 and why?
writing code in timeline can be quicker to start. writing proper code might take longer to setup but later when you want to make any changes or additions it is much easier and sensible. timeline code is hard to track down when the project gets complex.
I believe, I program good, at least my code produces results...
But I feel I have drawback... I hardly follow any naming conventions... neither for variables.. nor for methods... nor for classes... nor for tables, columns, SPs... Further to this, I hardly comment anything while programming...
I always think that, Let me first see the results and then I will come and correct the var names and other things later... (Thanks to visual studio's reflection here)... But the later does not come...
So, I need tips, to force myself to adopt to the practice of following naming conventions, and commenting...
Edit : I totally understand the ill effects of my practice, and I also know, that it is bad... My question is how do I force myself to follow the discipline...
Are you able to ask others for code reviews? Or even try pair programming? Both of those can really help you to do things you know you really should do.
Also, depending on your language/platform, there may well be lint-like tools you can run to check your code's health.
I hope you get to spend a few years working on code produced by someone else that has the same poor coding practices that you have. Only then will you truly understand how poor your code really is. Code that "works" is the bare minimum, writing code so that it is easy to to support, extend and maintain is where the genius of a good programmer is.
My gut tells me that your code is probably not as good as you think if you have no standards. You really just have to pick something, and stick to it. Being haphazard in coding style probably means you are haphazard in logic, which probably means you have a lot of bugs, and unexpected results in your code that will be hard to deduce later. Good luck.
Just remember the general coding guidelines you need to follow. And as you write the code write as per the guidelines with proper variable naming conventions for variables and methods and have function headers. Dont think whether your code will work or not, and code as per the guidelines.
Comments can be added later, but the naming conventions has to be followed even while doing a proof of concept.
Write your code with a confidence that its going to work.
Have your code reviewed by your peers, and also you can use Fxcop for static code findings.
Best of all, your code should work and should do what it's supposed to. It's what you get paid for.
However, if it is not readable, then it will fade into existence, because in time you will not remember what it does. To avoid this, refactor and document your code as soon as it works. As a rule of thumb, you should not be satisfied with your work before it is documented properly. For each method you write, this should not take too much time. But the longer you wait, the more time it will consume to figure out what your code was supposed to be doing.
I know the best way of all is to document before writing, but that won't work with cowboy coders. The other way around might be a good alternative, because readable and good documented code shows off a developer's skills.
This is a matter of coding discipline. If you want to prototype something and then throw the code away, this is acceptable. However, the instant you need to reuse or debug your code, you will regret having no comments and poor method/variable name choices.
While you are working with the code now, you know what it is doing. In a few months to a year, you will not remember everything so clearly. Then, you will likely regret not commenting your code and not choosing good names.
Consider, too, if someone else were to read your code, how easy would it be to understand?
Running something like StyleCop (if you're writing C#) can go some way towards this. It won't warn you about everything, but you can use it to make sure your methods have documentation comments etc.
However, as others have said coding discipline is something that has to come from within, not without.
If you want to change something about yourself, you need to motivate yourself to change it. That's one of the "rules of life."
This isn't really something Stack Overflow can help you with. I suppose that a good suggestion to build up some motivation is finding yourself a job as a developer and see how far your development habits lead you...
-Carlos Nunez