Seemingly Bizarre Type-Coercion Error
What The Flex?!
About an hour ago I started work on a new class and ended up with quite a strange error message which looked a little like this (the names have been changed to protect the innocent)
TypeError: Type Coercion failed: cannot convert Project.folder::MyClass@2d28301 to Project.folder.MyClass
Spot the oddity?
Cannot convert Project.folder.MyClass@2d28301 to Project.folder.MyClass. Hmmmm.
This one had me a little stumped.
The project I’m working on at the moment is modular and the only difference I could see was that this object was both created and added to a global collection from within a particular module, then I was attempting to retrieve it from the next module, whereas all the other data objects were instantiated in the application start up process, then retrieved from within various modules.
Solution
A quick post on FlexCoders got me the answer I was looking for. My object belonged to a different Application Domain than the rest, and therefore as far as Flex knew, these two classes were different.
The fix was to specify the ApplicationDomain for my module loader:
[as]
_mainModuleLoader = new NoviaModuleLoader(); //extends ModuleLoader
_mainModuleLoader.applicationDomain = new ApplicationDomain(ApplicationDomain.currentDomain);
[/as]
Thanks very much to Ian Thomas on FlexCoders for providing the solution.
You may also be interested in reading this.
11 Comments so far
Leave a reply
No problem. :-)
That’s an interesting problem with loaded Modules that define the same class in each module. I was wondering how that would work, since theoretically each module could define the same class in the same package with different source code behind each of them. I’m guessing that could only be a runtime error (not a compiler error).
It looks like the full identity of a class is the package name plus the class name PLUS the application domain instance (which I guess is created dynamically when a module or application is being loaded).
I would also think that it’s best whenever possible to typecast as an interface rather than a class, just to make sure that it’s not implemented differently between the application and the module.
I’m also getting this error and am not sure I’m understanding why. I have a SWF with a document class of VideoSWF. I’ve got another class, VideoSWFEvent, where when the video swf associated with VideoSWF reaches a certain point on the timeline, it runs a method which in turn, inside of VideoSWF, dispatches a VideoSWFEvent.
When I load this video swf into my main app, I’m getting this when the event should be dispatching:
[as]
TypeError: Error #1034: Type Coercion failed: cannot convert com.jcp.brandc.mainModule.view.settings.events::VideoSWFEvent@294c8671 to com.jcp.brandc.mainModule.view.settings.events.VideoSWFEvent.
at flash.events::EventDispatcher/flash.events:EventDispatcher::dispatchEventFunction()
at flash.events::EventDispatcher/dispatchEvent()
at com.jcp.brandc.mainModule.view.settings.video::VideoSWF/showLastHotspot()
at com.jcp.brandc.mainModule.view.settings.video::VideoSWF/com.jcp.brandc.mainModule.view.settings.video::frame225()
[/as]
I tried adding in the line of code you suggested but it did not work. I’m probably putting it in the wrong place as I’m actually not the one doing the loading operation (i was just casting it in my class as a MovieClip, we have a load manager thats taking care of the loading and caching objects, we just call it on the fly as needed) so I imagine the problem spawns because of that and my inability to add that line to where its actually being loaded, but all in all this is just a custom event thats being spit out, not a class that is being used as a base class or anything. any ideas? maybe i’m totally wrong about this in general? any help is appreciated as i’m grasping at straws at this point. thanks in advance.
Hi Matt, I think the issue is the same as mine. When loading movies in to other movies, it is possible that you could have a name-clash where both movies have classes of the same name and which are in the same package, but may do something different or, more likely may need to belong to a different scope – not 100% sure of all the reasons behind it, but some are mentioned here:
http://livedocs.adobe.com/flex/3/html/help.html?content=18_Client_System_Environment_5.html
This seems to be what the player is guarding against. As you’re using Flash I guess your main movie is using the Loader class. You mention that you don’t have a reference to the loader object, but your main movie’s loader may need to specify which domain it is loading its sub-movies in to. this partitioning is explained fairly well in the link above.
The key is to let the player know that it should treat the code from your movie as if it was code defined in the main movie.
Also take a look at ApplicationDomain (http://livedocs.adobe.com/flex/3/langref/flash/system/ApplicationDomain.html) and LoaderContext (http://livedocs.adobe.com/flex/3/langref/flash/system/LoaderContext.html) – these should help.
Cheers,
Neil
Neil,
Thanks, we got it worked out. The person editing the actual loading code didn’t commit their files into SVN but they had made a similar change. When committed, of course, it worked :P
Our fix (if I’m not mistaken at looking at the code) is something to this effect:
var imgContext:LoaderContext = new LoaderContext(false, ApplicationDomain.currentDomain);
Hopefully you aren’t unloading and reloading these modules repeatedly though, because loading into the same applicationDomain (from my experience) is almost a surefire way to create memory leaks. This seems to have been confirmed by Alex Harui: http://blogs.adobe.com/aharui/2009/08/what_we_know_about_unloading_m.html.
I have a potential solution, but it might take a whole blog post to explain…
Hi Ryan.
I read Alex’s post on Friday yet I don’t think he is confirming memory leaks caused by loading/unloading modules, but rather stating that as long as references are cleared up properly, there is no known reason that the module should remain in memory(?)
We actually changed our application a few months back specifically to reload modules each time, whereas before they were loaded once and held on to. We found that keeping the module in memory gave rise to other issues (such as the need to ensure state/display reinitialised correctly whenever the module was ‘reloaded’). This and other small issues seemed to lead to unnecessarily complexity in some areas of the code.
Reloading freed us from this, and while I’m aware of some minor memory leaks which do need attention, our tests don’t seem to indicate that reloading the modules each time has had a negative impact. Of course ensuring there are no references is easier said than done, and some info will remain until garbage collected (we both know the issues with that).
If you do find time to blog about the solution please feel free to post a link here. Very interested to read it, and as this is the first modular application I’ve worked on, I’m keen to converse with people who have more experience in this area :]
Cheers,
Neil
Please, be also aware of the implementation of the clone():* method on the objects registered as RemoteClass, in conjunction with Modules. From what I can see, just adding a clone()* method that leverages ObjectUtil.copy() method in such a scenario could lead to similar object casting / conversion issues. In such a case clone()* method should leverage new SomeObject() statement, and should be overriden in the classes that inherit from SomeObject class.
Thanks a bunch! This helped me solved a year-old problem that was preventing me from fully decoupling my modules from the main application!
Cool, glad it helped :)
Thanks a lot mate! I was almost cutting my pulses… :)