ActionScript 3 Tip of the Day

[beginnerscripte]

I'm just trying to create my own video player with flash 9 as3, but I can't get it to resize. I'm not an expert, but I looked all over the net and still can't find a solution to my problem. Every time I start this code, it plays back the flv flawlessly, but get this error message:

TypeError: Error #1006: setSize is not a function.
at flvplayertest_fla::MainTimeline/flvplayertest_fla::frame1()

, and can not get "setSize" to functioning. Please provide me a simple solution I still can understand Thank you!
Here is the code:

//video player

var nc:NetConnection = new NetConnection();
nc.connect(null);
var ns:NetStream = new NetStream(nc);
var vid:Video = new Video();
var GeVideoPlayer:MovieClip = new MovieClip();
this.addChild(GeVideoPlayer);
GeVideoPlayer.addChild(vid);
vid.attachNetStream(ns);
ns.play("1_hi.flv");
ns.addEventListener(NetStatusEvent.NET_STATUS, netstat);
function netstat(stats:NetStatusEvent) {
trace(stats.info.code);
}
var netClient:Object = new Object();
netClient.onMetaData = function(meta:Object)
{
trace(meta.duration);
};
ns.client = netClient;

// properties

GeVideoPlayer.x=100;
GeVideoPlayer.y=100;
GeVideoPlayer.setSize(100,100)


Thank you!!!!

[patrickjv]

Originally Posted by senocular

For making your own components? Adobe should have an article on this sometime in the future. Until then, community postings like the one on flashbrighton is the best there is ATM.

Senocular;

As you see on Flashbrighton page, I also mentioned;
I actually have managed to get/set a component parameter using the V2 way of a custom UI .swf file ... no componentShim and complicated routine

Using 2 ways.;
- _root.xch. (V2 way of custom UI .swf targeting component parameters) in the custom UI but of course you'll need to generate a AS2 UI .swf for it to work
- MMExecute with fl.getDocumentDOM as explained in JSAPI documentation

Both ways appear to modify a component parameter value. This parameter, when defined as var in first frame of component, is updated by a component placed on stage and any animation using the var in calculations actually changes the visual result. So it seems to work fine. I'm only starting to read AS3 stuff so have little Id if I'll run into problems but at least it looks promising.

People keep mentioning AS3 components are .fla based. I've been selling components for years and I've always provided them as editable Library content (non-compiled). So still see no reason to use the Shim stuff.

Maybe something to check in future. I've seen a number of people asking about it.

Currently going through your "Getting started with AS3 in adobe flash cs3" on your site, very nice!!! Still can't see WHY do most/everything in external AS files but hope to have some revelation at some point. Doesn't make sense yet

P

[ImagineFlash]

it is drea come true for me

[Dazzer]

Currently going through your "Getting started with AS3 in adobe flash cs3" on your site, very nice!!! Still can't see WHY do most/everything in external AS files but hope to have some revelation at some point. Doesn't make sense yet

Quite simple.

Say you made a ball. for 1 application. Some day you want to use that ball again in another application. Do you recode? No. Do you dig in your code for a particular segment of code and copy paste? No.

Just place the file(class) in the appropriate directory, and access it. Saved you time and effort.
Not to mention the amount of time saved to find class-specific code in large applications.

[dcampos]

Originally Posted by senocular

ActionScript 3 with Flash 9 lets you specify a "Document Class" (aka Application class) for the main timeline. This represents the class of the root object - the display object in which (essentially) all other display objects are placed.

Looking for some insight...Here it states that the flash player creates and instance of the class that is specified as the document class. But the behavior that I am experiencing does not appear to make an instance. I am extending MovieClip to add functionality I like to use; for example, a loadMovie function that simulates loadMovie in AS2 so that I don't have to define events all of the time. I call it RSMovieClip.

So, I define the document class as RSMovieClip also I have 2 symbols (symbol1 and symbol2 both exported for actionscript) in my library I define the base class for symbol1 as RSMovieClip. If I drag symbol1 on the stage and in the first frame a do a addChild(new symbol2()); symbol 2 gets added to the stage and symbol1.

Could you explain what is going on? Also you will see that the first frame is being called twice.

I have uploaded example files.

[Dazzer]

addChild is the same as dragging a symbol out onto the stage.
By dragging a symbol out and placing it on the stage you do not need to addChild as it is already part of the displayList.

Also, the reason why you might be getting recursive functions is because you've defined your base class of symbol1 as RSMovieClip which is your documentClass. When you define a base class, the symbol EXTENDS the base class. So whenever symbol1 is instantiated, it instantiates the Base Class (which is basically the superclass). So that's not what you do.

Most of the time, your symbols will have a base class of 'flash.display.MovieClip'. More advanced users will use either 'flash.display.Sprite' or 'flash.display.DisplayObject'. Very rarely have I had to extend an already existing symbol.

Make a DocumentClass called DocumentClass. Assume that whatever you put in the DocumentClass is what you'd normally put in Frame 1 (though its really not the same, but its almost the same). And that's basically all you need to do. Don't make it so complicated.

[dcampos]

I think your missing the question, I was under the impression that when you define a document class it is an instance of the class not the definition of the class. From the examples I posted the document class is altering other symbols that use the the same class. I'm not looking for a work around or fix just trying to understand how flash is compiling/or running the script.

This is important to me because we develop course ware that will load multiple swfs having the same document class (probably not anymore) and if each swf is altering the document class then I wanted to know what will happen at runtime when loading in those swfs; will all swf's use the first definition of the class that was loaded?

For us, It does not seem reasonable for us to create a unique document class for each swf we load when they all have the same properties and methods. Some of our courses have over 100 "content" pages not including the support files. So before we rethink how we are converting our course engine to as3 I want to understand this behavior I am seeing.

We have contacted adobe support on this and they have escalated our issue twice now, and we are waiting another call from the next level of support. When I have an answer I will post it here.

[Dazzer]

This has happened to me recently(by pure accident of course)

I had a app using a document class. In the documentClass's constructor I told it to load something. And I accidentally loaded itself into itself.
What happened? Perpetual loop.

The DocumentClass is the definition of the class yes.
Each swf that uses that as ITS document class, however, is an instance of it.

If all your course swfs are the same, they can probably use the same documentClass. However, you should rethink whether it is possible to decompose it into a lesser form. (plain swfs, with a external "player" that will do all actions instead of all swfs having next and forward buttons, for example)

If I drag symbol1 on the stage and in the first frame a do a addChild(new symbol2()); symbol 2 gets added to the stage and symbol1.

Now the problem here (I misread, but it is still similar) is that IN YOUR DOCUMENT CLASS you have told it to addchild(new symbol2()). However, symbol1 is also an instance of the documentclass (or well, you actually used the documentClass as a BaseClass, which is , in effect, extending it; that I noted earlier in the previous post) . So that is why both of them are adding AddChild(2).

Again, your swf is AN INSTANCE of the documentclass. It does NOT CREATE AN INSTANCE of it on the stage for you.

[Matthew Ford]

I've been reading a few OOP books (the AS3 one by Lott in this case) as well as this forum and I've noticed this phenomenon once again. I am a big fan of composition, just like senocular and Lott and others. But in their examples, they often forego composition when it comes to event dispatching.

For example, let's say I have a game object-- a balloon that pops when clicked. In the Balloon class I compose in a sprite for the balloon graphic and addEventListener to that sprite so that the class internally processes the click to trigger the pop animation. So far so good.

Now I want a scoreboard to listen to the Balloon object so it knows when a balloon pops. I'd want the board object to do something like:

 
balloonToHear.addEventListener("popped", scoreHandler)

It seems a true composition buff would also compose into Balloon an EventDispatcher object, make Balloon implement the IEventDispatcher interface, and make that ED object send the custom "popped" event. Sure, one has to catch and pass through to the composed ED object a few event functions, most notably AddListener, as well as a few others to satisfy the interface. But that seems to be not a big deal, and in fact these books do often say that this is a possible approach, as a side note.

But these same books often lose their taste for composition in this case and in their examples instead generally go the other route: they have Balloon *extend* EventDispatcher, and not compose in an EventDisptacher object or implement IEventDispatcher. Sure, this approach also works and avoids the need for Balloon to contain all that pass-through code. But it breaks the "is-a" versus "has-a" rule that composition buffs should embrace. The Balloon is not an event dispatcher-- it does many things besides dispatch events. It seems like a classic "has-a" relationship.

My question is, why do these books and sites I am reading, which usually so strongly advocate composition over inheritance, tend to use examples of the second type (extension) rather than the first (composition)? Is there some horrible consequence of using composition for EventDispatcher functions than I am unaware of? Am I being too doctrinaire? Or it just because it makes the example a bit simpler for the purpose of illustration, and they just assume that I will do the right thing and convert it to composition myself?

Originally Posted by senocular

... Normally this means objects whose class extends EventDispatcher. EventDispatcher, however, can also be used with composition (having an instance defined within the class instead of inheriting from the class to gain the same functionality). ... it, like EventDispatcher, should implement the IEventDispatcher interface.

[Dazzer]

Its all subjective isn't it? I could still say a Balloon dispatches an event. And you couldn't say anything to refute that. So I'd say its up to the developer.

For example, when a Balloon pops, do you hear a balloon popping, or do you hear the sound of compressed air decompressing at high speeds? While it could be both, most people would first associate it with? A balloon popping. Which is the event we're looking for.

However I'll let Senocular do the rest of the talking Its an interesting topic.

[senocular]

Id say it is one.

[sger_error]

from a class that extends MovieClip mouseX, mouseY properties of the root


(in the past _root._ymouse).


any ideas...

[Dazzer]

Try starting a new post and we can get back to you.

[senocular]

ActionScript 3 now embraces a much more strict enforcement of encapsulation - or maintaining individual isolation within classes. A primary example of this is root and stage access. Now, not every class can access the root or stage directly, not without being given an explicit reference or, for display objects, by being added to the stage's display list from an outside source (or outside reference).

What this means is a change of how you need to approach programming with Flash ActionScript 3.0. Now, instead of taking the approach of Inside Looking Out you need to think in the way of Outside Looking In.

What does this mean? This means you cannot create a class and expect that class (or its instances) to be able to pull values or reference content defined outside of itself. This is inside looking out - inside a class trying to get things from outside of that class when in ActionScript 3, there just isn't any access, not inherently.

With ActionScript 3 you have to instead start on the outside and look in. You need to have classes that are tools for an outside class where that outisde class uses and digs into to make that other class work for it. And that outside class might be tool for another class using it and so on and so forth until eventually you get to your root or document class, the root node of the Flash movie or application in which everything is defined - the very class that has absolute immediate access to stage and root.

What does this mean in terms of programming in AS3? It probably means mainly 2 things:

• Having a greater dependancy on events and dispatching events to send messages and information to other classes
• Relying more heavily on passing references to new class instances so that they can reference external data if they need to and

Case 1: Using Events
Consider a Button class. Simply, buttons get clicked and then do things. What they do can vary based on how they're used. The buttons themselves, to maintain this kind of flexibility never need to know what they do, just that they get clicked, and when that happens, let the user of that button know so it can react appropriately. This happens in the form of an event an outside controller class (the one who made the button) would have created a listener for the click event of the button to creact appropriately when the button is clicked.

• Controller
  
  • defines reaction to button click
    
  • creates button
    
  • listens to button click and have it call reaction
    
• Button
  
  • listens to user clicking
    
  • when clicked, dispatch event to any listener (controller)
    

Outside looking in - controller looking into button for button occurences (click) and then reacting on its own. The button doesn't need to look out. This concept not only applies to buttons but many other classes (and not just UI) as well.

Case 2: Passing References
Consider a game consisting of a map and a player that interacts with that map. Both the player and map have their own class definitions (lets say Player and Map repsectively). In ActionScript 2 what you might consider doing is having a Map instance defined in the _root timeline (called map) and the Player instance referencing that map using something like _root.map.

This is bad. First off, its breaking encapsulation by having the Player reference an outside property. It's also assuming that there is this object _root (which changes for every SWF) with a definition of map that it expects to be a Map instance. If this Player class is ever to be used in another FLA, that FLA would have to have the same _root definitions as expected by the Player definition. And how easy is it to know what is expected of all classes that behave like this? What other classes might expect there to be definitions in _root?

A better approach would be to keep the Player instance from looking outside and instead have it accept a reference from the outside (outside going in) which it can use to interact with external data. Then, when the Player is created, it can accept within its constructor a reference to the Map instance that it can then use internally to access Map data. No longer is this map restricted to exist in _root or any other specific location; it just needs to be sent to the Player instance to be referenced by that instance. And if needed, the player reference to the map can easily be changed to reference another map dynamically without changing the original definition of the first map.

var map = new Map();
var player = new Player(map);

ActionScript 3 further enforces this by keeping root and stage from being globally accessible from any class. If you want any class to have access, it will need to be given access explicitly from an outside source (even display objects since an outside source is needed to add them to the display list).

[Pattt]

When I use:

MovieClip(root).removeChild(this);

... I get this:

TypeError: Error #1009: Cannot access a property or method of a null object reference. at cell/enterFrame()

"cell" is the mc, and "enterFrame" is the function.

What's wrong?