Comments on: The Natural Entry Point Method (Tutorial & Source Files) – Introducing A New Way to Create Flash Applications Using Swfmill and MTASC

By: {Code}Trip » Flash em ambiente Open Source

{Code}Trip » Flash em ambiente Open Source — Sun, 11 Oct 2009 04:20:50 +0000

[...] subclasse de MovieClip como novo "ponto de entrada", Document Class. Este processo foi chamado de Natural Entry Point por Aral [...]

By: Monte Aspevig

Monte Aspevig — Tue, 07 Apr 2009 22:46:19 +0000

Great article Aral, I’m trying to adapt the sphere animation so it uses a single tween in the constructor instead the onEnterFrame method (code below). I’m embedding the application.swf in a container swf that allows the user to switch between swf’s. The animation plays correctly the first time the swf is displayed but fails if the swf is displayed again.

>>> modified particle.as code >>>

import mx.transitions.easing.*;
import mx.transitions.Tween;
class Particle extends MovieClip
{
function Particle ()
{
_x = 10;
_y = 10;
var tween:Tween = new Tween(this, “_y”, Strong.easeOut, 300, 65, 2, true);
}
}

By: Daniel Worthington

Daniel Worthington — Mon, 07 Jul 2008 21:11:32 +0000

Perhaps a silly question, but where do you get the MX 2004 class files from? Is that something that just gets installed with Flash, or is there another way to get those files? Also how do those class files differ from the files that come with mtasc in the std and std8 folders? Finally, I have been successfully building projects without the MX 2004 classes in my classpath. Do you find you use them often for your projects? Thanks so much for your helpful articles. Your blog has been super helpful for me.

By: Alexander Bethke

Alexander Bethke — Sun, 13 May 2007 18:10:38 +0000

Heippa, nice approach, and indeen a very well written article,

just for anybody considering of adapting the method: The general disadvantage is that you cannot access the content of included library-swf’s by script, as MTASC does not know them at compile time and complains about not-exsisting properties. So if you use swf’s you want to dynamically tweak later by script the Skeletal Injection Method works better. If you use the swf’s as passive content the Natural Entry Point approach might be something to have a closer look at.

Have fun finding your own ways in ActionScript.

Alex

By: RetroJ

RetroJ — Mon, 05 Feb 2007 03:28:57 +0000

Thanks for this very nice article. It was very helpful, even though I’m writing in haxe, not actionscript. I did want to mention that the source code examples are very hard to read, at least in the browser I’m using, because the scroll-boxes were too narrow, so I had to constantly scroll left and right to read the code.

By: glantucan

glantucan — Mon, 06 Feb 2006 18:18:41 +0000

Thanks a lot. See you there :D
Glantucan

By: Aral Balkan

Aral Balkan — Mon, 06 Feb 2006 17:28:00 +0000

Hey Glantucan, check out the OSFlash mailing list. It'll be easier to have this conversation there and others can help out too! :)

By: glantucan

glantucan — Mon, 06 Feb 2006 17:21:18 +0000

Well, I realized I made a mistake, thinking it's the compiler who spits out the traces.

I see now you need eclipse and flashout for that.:D

But, as the natural entry point it's not working in that manner there must be another way, am I right?

Perhaps, this is not the place to ask about that.

Would you kindly tell me where (forum or mailing list) could I ask you or other about this?

Thank you very much

Glantucan

By: Aral Balkan

Aral Balkan — Mon, 06 Feb 2006 15:22:06 +0000

What are you looking to trace? Tracing a value should work normally regardless of which entry point method you use. I don’t understand the question :)

By: glantucan

glantucan — Mon, 06 Feb 2006 13:53:12 +0000

Hello Aral,

I started using your method just today, it's just wonderful, but...

How can you use trace() on it.