Thursday, 14 February 2008

a possibly undefined method

It's undefined... possibly.

Maybe it's undefined or maybe it's actually defined. We don't know.

Given that calling a method is quite a common thing to do how is this better than "there's something wrong" in terms of helping you fix it.

1061: Call to a possibly undefined method X through
a reference with static type Y

Well, possibly a bit. Possibly.

Anyway here's where I went wrong.

Variable at the top of my (so I can access it everywhere) like so - it's using a class I wrote for a different project (do you hear that? reusable code. I like totally rool!).

var thing:ClassA;


I've not assigned anything to it yet I'll be doing that in the class somewhere. In fact here I am doing it now.

thing = new ClassA(var1, var2);


So all is well and good until I realise that despite the joys and karmic benefits of reusable code ClassA just isn't going to cut it with this new project. It's got the juice but I'm going to be needing biscuits with that juice if you know what I mean (tell me if I'm loosing you here).

So a quick new class.

class ClassB extends ClassA
{
/* new stuff */
}


and a change to the code

thing = new ClassB(var1, var2);


and I'm away using the new stuff and making good things happen. But no... I get that error above there. I'm scratching my head because as far as I know the whole thing with this class based OOP based programming shizzle is to do just that kind of thing.

And the method is there. It's fucking there. Look I extended ClassA and WROTE A NEW METHOD! Here it is! Aaaaarrgh!

Anyway turns out (as usual) I'd missed something. You see at the top of the class there when I defined the variable (but didn't assign anything to it) the variable was still being given a type of ClassA.

var thing:ClassA;


and it seems that because of that, even though I assigned an object of type ClassB to it later on. It never really got over being a ClassA. In fact it as so attached to it's status as a ClassA varaible it kind of ignored everything about ClassB that it didn't already know.

Hence when I come to call on one of my new methods, they "officially" didn't exist.

Possibly.

Tuesday, 12 February 2008

addChild and removeChild and references.

I've just found a tricky little thing which I didn't know before which might be of help.

I've declared a variable "img" which will be available from where ever I need it in my Document Class. It's declared as a Loader and when I come to load the image into it I use the following code.

img = new Loader(firstUrlRequest);
addChild(img);


Then later on I want to replace the image. My idea was that I'd simply re-use the "img" variable and load a new image into it like so:

img = new Loader(secondUrlRequest);
addChild(img);


This seems to work fine and new images keep on appearing as I re-use this code at various times within the interface.

Until I want there to be no image there. Then there is a problem. I use:

removeChild(img);


and sure enough the last image I added is gone, but wait, what's that? The image before that is still there. How the heck am I accidentally adding that back in?

The problem goes back to the fact that the img variable isn't the same as the Loader I've added to the stage. It's just a reference to that Loader. So what happens when I make the img variable reference a different Loader (i.e. the new one I've added)?

What happens is I loose my control over the original image. It's still sat there on the stage but now I have no way to connect to it (except perhaps by some iteration through the stage's children and possibly using removeChildAt).

So the moral of the story: if you're reusing references to load different objects onto the stage (to replace each other) make sure you removeChild the referenced object first, that way you'll have nothing floating around in the background to surprise you later.