Actionscript: Problems with implicit coercion

Question

I'm following hemanth sharma's excellent tutorial series on the starling framework. I more or less copied his code and made a few changes towards the game I have in mind. The code is 80% the same he used in his project. Nevertheless I'm encountering a strange error: "error 1067" it complains about the "implicit coercion" of supposedly unrelated types.

I browsed previous questions and discovered this one:

1067: Implicit coercion of a value of type Class to an unrelated type flash.display:DisplayObject

The error message I'm receiving is basically the same but unfortunately the solution does not apply to my problem. Moreover I'm getting this error in many interesting different flavours.

I've got a custom event class called NavigationEvent that expands starling.events.Event. When the used tries to switch between the game screens this event is dispatched. Here's some code:
```
import starling.events.Event;

public class NavigationEvent extends Event
```
it is dispatched like this:
```
this.dispatchEvent(new NavigationEvent(NavigationEvent.CHANGE_SCREEN,{id:"play"},true));
```
the error message says:

Error 1067: Implicit coercion of a value of type events:NavigationEvent to an unrelated type starling.events:Event

The code worked fine when I first wrote it but now, after I've changed another part of the program it is broken. I can't explain it. I extended NavigationEvent from starling.events.Event so the types are definitely not unrelated. I even ran the program like this. Admittedly the routine to switch between screens was no yet implemented but the event was fired without problems.
In order to let the user trigger this event I added a button to the screen. It is starlings standard starling.display.Button;. The button is a member variable of my screen class
```
private var playBtn:Button;
```
However this line results in an error:
```
playBtn=new Button(Assets.getAtlas().getTexture("play"));
```
This time the error is even more outrageous:

Error 1067: Implicit coercion of a value of type starling.textures:Texture to an unrelated type starling.textures:Texture

What can I do about this ?

+1 for a clear description of the problem and showing previous research. — Amy Blankenship
Ok, so I would break your dispatchEvent code into two lines and trace and set break points. Also, are you working on this in Flash Builder, and is there a chance that you could have had 2 projects open at the same time that reference the same code? — Amy Blankenship
I am working in FlashBuilder and just closed all other projects. Now everything works fine. The error just vanished. I have no idea how this is possible. It came and went arbitrarily. I can't imagine how the other projects could have influenced this, since they use the same code for navigation but in different files in a different directory. Your advice sounded like magic but it worked. You might want to make it an answer - I would happily accept and upvote it. If possible I would appreciate a more detailed explication and would be glad about a link to read up on this topic — lhk

Amy Blankenship Amy Blankenship · Accepted Answer · 2012-11-03T21:28:17

Sometimes, when you have two Flash Pro projects open in Flash Builder, and both projects have the same directory in the code path, you can get the error you experienced. This happens when you have the file open in one of the projects, but you're compiling and running both of the projects (especially if you're debugging and have set break-points).

What I think is happening is that FB compiles in the same file as if it were a different file, because it is "reaching over" from the one where the file is open and compiling it into the one where it's just referenced, but not open. The file that is open extends the base Class in its project, not the base Class in the project with the fla/xfl in it. Though we know that it's actually one file, FB apparently can't figure that out. I think you got off really lightly, because I've had to take truly heroic measures in the past to resolve this.

You could potentially resolve this by moving your shared code out into a library project, which I think is the scenario the engineers probably thought everyone would do. I think that they couldn't (or at least didn't) foresee the intersection of historical Flash development practices and the quirks of working with FB and FP together that would cause this particular bug to emerge.

Actionscript: Problems with implicit coercion

1 Answers