CustomEvent class issue

[Ned Murphy]

I make use of a CustomEvent class, one which I believe is standard since when I went to create it at one point, I swear Flash filled in all of the code for it before I could paste it in.  I use it to have swf's that are loaded by a main file capable of dispatching an event with some data to go with it.  The code for the class is shown below at the bottom.

The CustomEvent class file is planted in a com folder structure that is defined in my classpath for Flash

It works fine for me when it works, but it seems like anytime I start a new directory/collection of files for a new/divergent revision of the main file, the published swf's produce errors with respect to the CustomEvent class when I try to load into the main file...

TypeError: Error #1034: Type Coercion failed: cannot convert com.path::CustomEvent@80ac1c1 to CustomEvent.
at flash.events::EventDispatcher/dispatchEventFunction()
at flash.events::EventDispatcher/dispatchEvent()
at loadedswf_fla::MainTimeline/frame23()

What ends up fixing this is publishing the files again within their new folder structure.

I have always been under the impression that once you publish an swf it burns in the code that was used in its creation and no longer requires the AS class files that were used in creating it.  But this one seems to defy that. 

Do you know why this happens and what might be done to not have to remedy it by republishing? There are quite a few of them which makes it a bit of a pain each time a new variation comes about.

Here is the class file code:

package com.path

{
     import flash.events.Event;

     public class CustomEvent extends Event
     {
          public var params:Object;

          public function CustomEvent(type:String, params:Object, bubbles:Boolean = false, cancelable:Boolean = false)
          {
               super(type, bubbles, cancelable);
               this.params = params;
          }

          public override function clone():Event
          {
               return new CustomEvent(type, params, bubbles, cancelable);
          }
         
          public override function toString():String
          {
               return formatToString("CustomEvent", "params", "type", "bubbles", "cancelable", "eventPhase");
          }
     }
}

[kglad]

if you have the above class in com.path and your have another class named CustomEvent in the directory with your swf (with no package specification), even though you import com.path.CustomEvent, flash will use the CustomEvent class in the default directory.  it won't use the com.path.CustomEvent class.

when you move to a new directory, there is probably no CustomEvent class in that directory and all works as you expect.  if there is a CustomEvent class in the default directory with the swf, when you direct flash to create that (com.path.CustomEvent) file, it fills in the code from that (the default directory CustomEvent)  class.

[Ned Murphy]

What would be the ideal setup for having the file planted in a common .com folder?

Now to confuse regarding locations of the class file...

There is no copy of the CustomEvent class in the folder that contains the flas that create the swfs, nor in the folder that contains the swfs.

Because I have used this CustomEvent class for various projects, I keep a copy of it in my immediate classpath folder.  So based on what you said, there is a chance that the first CustomEvent file in the classpath is what gets seen when I publish rather than the one in the com.path folder

This same folder contains the "com" folder wherein via the "path" it has another copy of the same class file.  This is because this project has a set of custom-made class files, and the CustomEvent class has been grouped with them in that folder named "com" with the files in the same "path" so that all of the project class files have common location for sharing them with other developers when things change.

While I don't think it matters in this case, there is also a com folder that sits in the main project folder as a repository for the various class files for the whole project.  I say I don't think it matters because it is a folder that is parallel to the folder that contains the flas and another folder that contains the swfs that the fla's publish.

One thing that adds to my own confusion is that none of the other class files that live with the CustomEvent class in the com/path folder(s) have this issue... though when those get run it is usually the main file being compiled when it is run, not a saved swf using the CustomEvent class. 

The main file imports the project classes using

import com.path.*;

Since that local com/path folder sits parallel to the main file (same parent folder), I am imagining it is really using the local com/path versions and not the one intended in the classpath.

Could it be that the main file is using a different copy of the class file when I test and regardless that it is an identically coded file, it is not the same physical file and things fail as they do?

I still don't understand why the file seems to be looking for the CustomEvent class after it has been published.  When the final product is put in place, it will not have the class files anywhere in sight, so I expect that the swf's should have everything they need published into them.

[kglad · Accepted solution]

What would be the ideal setup for having the file planted in a common .com folder?

you mean a com folder that has class files shared among different projects?

Now to confuse regarding locations of the class file...

There is no copy of the CustomEvent class in the folder that contains the flas that create the swfs, nor in the folder that contains the swfs.

Because I have used this CustomEvent class for various projects, I keep a copy of it in my immediate classpath folder.  So based on what you said, there is a chance that the first CustomEvent file in the classpath is what gets seen when I publish rather than the one in the com.path folder

if you have an identically named CustomEvent in a default class path (eg, assigned in the advanced actionscript settings panel's source path), the same problem occurs.  that class (in the default class path) will be used instead of the one from the import statement.

This same folder contains the "com" folder wherein via the "path" it has another copy of the same class file.  This is because this project has a set of custom-made class files, and the CustomEvent class has been grouped with them in that folder named "com" with the files in the same "path" so that all of the project class files have common location for sharing them with other developers when things change.

any same named class files that flash can access are potentially problematic.  to debug your setup, use a different trace() statement in the constructor of the various same-named problematic class files.  that will show you which class file flash is using.

While I don't think it matters in this case, there is also a com folder that sits in the main project folder as a repository for the various class files for the whole project.  I say I don't think it matters because it is a folder that is parallel to the folder that contains the flas and another folder that contains the swfs that the fla's publish.

it's only irrelevant if flash does not know these files exist.  if any of the files are in its class path, you have a potential problem.

One thing that adds to my own confusion is that none of the other class files that live with the CustomEvent class in the com/path folder(s) have this issue... though when those get run it is usually the main file being compiled when it is run, not a saved swf using the CustomEvent class. 

that's expected under certain circumstances.  one, there's no name collision.  two, the same-named class files are document class files. and there are possibly other situations.

The main file imports the project classes using

import com.path.*;

Since that local com/path folder sits parallel to the main file (same parent folder), I am imagining it is really using the local com/path versions and not the one intended in the classpath.

use the trace suggestion above to see what flash is using.

Could it be that the main file is using a different copy of the class file when I test and regardless that it is an identically coded file, it is not the same physical file and things fail as they do?

if you use one class file to create an instance, in another class/scope, that instance may no longer be the same class type used in that different scope, even though they're both CustomEvent class types.  ie, you'll get that unable to coerce CustomEvent to CustomEvent error.

I still don't understand why the file seems to be looking for the CustomEvent class after it has been published.  When the final product is put in place, it will not have the class files anywhere in sight, so I expect that the swf's should have everything they need published into them.

correct, swf files contain the compiled code.  after a swf successfully compiles it doesn't matter where it's located (with respect to the actionscript used) and it doesn't matter what or where the class files are that were used to publish it.  if you publish a swf that has no compile-time errors, running it will trigger no compile-time errors.  but, you may encounter runtime errors.

[Ned Murphy]

So I guess that if I eliminate all other than one copy of the CustomEvent file I will stand a better chance of not having the issue I have.

But at the end of your last response you indicate that... "if you publish a swf that has no compile-time errors, running it will trigger no compile-time errors.  but, you may encounter runtime errors." ...

The files in question are successfully compiled swf's.  The files follow the "independent child" approach to having a child communicate with the parent that loads it.  They merely dispatch events for which the main file has listeners assigned.  And the error messages I get are run-time errors. 

This is essentially a slideshow with slides being loaded dynamically as jpg or swf files.  When one of the swf files loads that incorporates the CustomEvent coding to announce whatever status it is announcing is when the error shown earlier erupts.

The problem with trying to incorporate any traces into the swf slide is that as soon as I compile/publish it within the file system, the problem goes away.  So I won't have a problem to chase with a trace I add to the slide.

I can poke around the main file to see if that's the culprit that is really generating the error since it is on the receiving end of the event via its listener.  But since republishing the slide file fixes the problem, I have my doubts.

I just put traces in the three different CustomeEvent files and published one of the swf slides to see where it is getting the class and it is from the base of the classpath (not the com location).  I added a line to dispatch a CustomEvent in the main file and it too gave the trace from the same base of the classpath.  And, as expected, when I run the main file using the newly published swf, the problem is gone.  The sibling swf's still have the error when their turn comes.

Here's where the solution starts to come into view (and possibly identifying the problem)...

1) I changed the name of the CustomEvent file in the base of the classpath so that it would no longer be the first choice for publishing.

2) I opened a different swf slide and published it, confirming that it now looks for the com.path CustomEvent file. 

3) I DO NOT move that newly published file into the slides folder, meaning the file that was given to me by another developer will be used.  I run the main file, confirming it too is now looking at the com.path class file and....

- the first slide that was published using the base classpath file has the error again

- the slide that was not changed, but was likely published thru the com folder by the person who gave it to me plays just fine, as do all the rest of the files that were sent to me which were previously erring

4) I republish the first slide and move both of the newly published slide swfs into the slides folder and the world is a happier place.

So like so many things in this world... the secret is... location, location, location. 

Somewhere along the line the processor is checking passports and knows where things came from and wants things that use the same name to come from the same location.

If you have any other knowledge to offer regarding this that corrects or disputes or bolsters what I just said, it is welcome info.

[kglad]

So I guess that if I eliminate all other than one copy of the CustomEvent file I will stand a better chance of not having the issue I have.

correct

But at the end of your last response you indicate that... "if you publish a swf that has no compile-time errors, running it will trigger no compile-time errors.  but, you may encounter runtime errors." ...

The files in question are successfully compiled swf's.  The files follow the "independent child" approach to having a child communicate with the parent that loads it.  They merely dispatch events for which the main file has listeners assigned.  And the error messages I get are run-time errors. 

yes, as mentioned each swf could compile (and run) ok but if they are using different versions of (what looks to you like) the same class, flash may consider one CustomEvent instance to be different from another CustomEvent instance and you get what looks like a nonsensical TypeError: Error #1034: Type Coercion failed: cannot convert com.path::CustomEvent@80ac1c1 to CustomEvent.  in fact, the more i look at that, the more it looks like there's a com.path.CustomEvent and there's also a CustomEvent in the default class path and flash does not recognize them as the same classes.

This is essentially a slideshow with slides being loaded dynamically as jpg or swf files.  When one of the swf files loads that incorporates the CustomEvent coding to announce whatever status it is announcing is when the error shown earlier erupts.

yes, and the main swf has another CustomEvent (probably using the event listener)

The problem with trying to incorporate any traces into the swf slide is that as soon as I compile/publish it within the file system, the problem goes away.  So I won't have a problem to chase with a trace I add to the slide.

put different trace() statements in the different CustomEvent class files.  when you see the run time error, you will see different CustomEvent classes being used.  you'll need to detect the trace in your browser or use something else like monsterdebugger or adobe scout.

I can poke around the main file to see if that's the culprit that is really generating the error since it is on the receiving end of the event via its listener.  But since republishing the slide file fixes the problem, I have my doubts.

I just put traces in the three different CustomeEvent files and published one of the swf slides to see where it is getting the class and it is from the base of the classpath (not the com location).  I added a line to dispatch a CustomEvent in the main file and it too gave the trace from the same base of the classpath.  And, as expected, when I run the main file using the newly published swf, the problem is gone.  The sibling swf's still have the error when their turn comes.

publish the sibling swf's using a different trace in the CustomEvent class they use.

// i don't understand what you're doing below but if you can to create one CustomEvent class in the the class path of your published swf(s) and duplicate the problem, post a link to the files.

Here's where the solution starts to come into view (and possibly identifying the problem)...

1) I changed the name of the CustomEvent file in the base of the classpath so that it would no longer be the first choice for publishing.

2) I opened a different swf slide and published it, confirming that it now looks for the com.path CustomEvent file. 

3) I DO NOT move that newly published file into the slides folder, meaning the file that was given to me by another developer will be used.  I run the main file, confirming it too is now looking at the com.apth class file and....

- the first slide that was published using the base classpath file has the error again

- the slide that was not changed, but was likely published thru the com folder by the person who gave it to me plays just fine, as do all the rest of the files that were sent to me

4) I move both of the newly published slide swfs into the slides folder and the world is a happier place.

So like so many things in this world... the secret is... location, location, location. 

Somewhere along the line the processor is checking passports and knows where things came from and wants things to be the born from the same location.

If you have any other knowledge to offer regarding this that corrects or disputes or bolsters what I just said, it is welcome info.

[Ned Murphy]

The project is an AIR-based project so there is no URL to post.  It is also an NDA-based effort so I couldn't really share details of the design beyond a generic description.

What the steps I numbered above were trying to show is that a file published with a differently pathed version of the CustomEvent file than the one the main file is using will fail when you try to play them together. 

When the two files use an identically relatively-pathed version of the file things play right, regardless that the actual files used to publish them are on separate machines. It's the different relative paths to the class file that is tripping up the processor (as you described in your latest response).  Somehow the processor checks a record of where the class code came from and rejects when they come from different pathed locations.

When I republished the files on my machine, they both ended up using the same pathed file again, which is why that fixed things every time, but it was taking a different path than what the other developer uses due to the base copy sitting where it was.  Then I would send the files back to the other developer and he would have to go thru the same deal at his end. So we ended up sending files back and forth where we had to keep republishing.

With our two file systems now matching after I removed the other copy of the class file at the root of the classpath, we shouldn't have this issue anymore.  Now I just have to hope whatever other projects used that base file don't come back to haunt me since it's no longer there.

[Ned Murphy]

I nearly forgot... Thank you for helping me figure this out.  The traces you suggested really helped.