error 1119 when class extends another class that extends movieclip

[dns r5]

hiya

i came across this problem and i have no clue why it's happening. basically, consider 2 nested movieclips on the stage, something like stage -> main -> filler.  both movieclips have instance names (main and filler).

in the library, i set main to export for actionscript, using class A:

package {
    import flash.display.MovieClip;

    public class A extends MovieClip {     
        public function A ():void {

            trace ('construct A');
            trace (this.filler); // should trace [movieclip] etc
        }
    }
}

it works fine. now i change it's export settings to use class B, that extends A, and it breaks:

package {
    import flash.display.MovieClip;

    public class B extends A {

        public function B ():void {
            trace ('construct B');
        }
    }
}

this throws an error 1119: Access of possibly undefined property filler through a reference with static type A.

can anyone give me a hint on that, as it works with class A, but not B extending A? i understand it was meant to work?

many thanks

[Ned Murphy]

You probably need to import A into the B package, instead of the MovieClip

[dns r5]

agreed, but the error persists..

actually, import A and MovieClip as well.

[Rodney_Pillay]

looks like you need to call super() inside class B

public class B extends A {

        public function B ():void

        {
           super();

           trace ('construct B');
        }

}

[dns r5]

afaik, if you dont declare super(), flash will make a call for you (but best practice is to call it always).

but i found the "solution" in another forum.

it seems that flash implicitly generates variables if you have instance names/symbols on the stage. there is an option to disable that under publish settings -> Actionscript version -> Settings -> automatically declare stage instances. by disabling that, we were able to declare public var filler:MovieClip; on class A, and that worked.

although, that solution doesnt look attractive to me. the other solution posted on another forum was to make calls to this ["filler"] instead of this.filler. that seems to work fine. i guess it has to do with the automatic variable generated thing.. who knows?

i hope that helps someone else too

[Rodney_Pillay]

try making a

private var filler:MovieClip inside class A .... you will then be able to reference the target as this.filler .

[kglad]

no, it's unrelated to importing A and unrelated to calling super.

the fact is, filler is a proprety of A.  the compiler just doesn't know it.

[dns r5]

just adding a private var causes another conflict and crashes too, giving another error -- 1152 i think? can't remember now.

[kglad]

that's a compiler error.  filler does exist in A.

[Muzak]

This is probably because of the (highly annoying) "automatically declare stage instances" feature.

File -> Publish Settings -> Flash tab -> ActionScript version, click "settings".

Disable "Automatically declare stage instances".

You'll then have to define the inner MovieClip through code in Class A.

package {
    import flash.display.MovieClip;
    public class A extends MovieClip {
        protected var filler:MovieClip;
        
        public function A ():void {
            trace ('construct A');
        }
    }
}

And if I'm not mistaken you'll also have to create and add filler through ActionScript (in Class A) instead of having it on stage (in MovieClip main).

[dns r5]

this does the job, it's just a little annoying having to declare every little mc in there, and some other collateral issues that can arise.

it's easier in the way suggested i've found on another forum, to use this ['mcName'] instead of this.mcName. works like a charm

[Rothrock]

It might be annoying to have to declare all the authortime placed instance, but I think it is worth it.

When you come back to work on this or update it or if you have multiple people who work on stuff it really helps to know where everything is coming from.

I usually put a comment around all the stage placed stuff so that it is clear in an instant where stuff is coming from.

The problem with using the this.['someString'] is that it bypasses the compiler checking and so you are likely to, at somepoint, have something that doesn't work and if it is a complex project you might take a long time to figure it out -- since you won't get any help from the compiler.