In the shared code module examples, I would put historyMgr in the shared code module and load it before anything else. Note that if you use the cached framework rsl correctly it should take care of the HistoryMgr problem.
Alex Harui Flex SDK Developer Adobe Systems Inc.<http://www.adobe.com/> Blog: http://blogs.adobe.com/aharui From: [email protected] [mailto:[email protected]] On Behalf Of grg_blls Sent: Thursday, March 19, 2009 11:35 AM To: [email protected] Subject: [flexcoders] Re: A ModuleLoader issue Hi Alex, hi Rob, thanks both for your replies. Rob I 've tried your suggestion but it didn't help.. So after visiting Alex's blog, doing some more reading and further invastigation (debugging) of my problem, I have come now to the following: - Alex is right about the Singletons. I traced the exact step where the app throws that error as in the following code from HistoryManager.as: private static function get impl():IHistoryManager { if (!_impl) { _impl = IHistoryManager( Singleton.getInstance("mx.managers::IHistoryManager")); } return _impl; } Now as I described in the first place, I was unloading/loading modules by the standard procedure (and I had the problem). Running the loop as desribed initially, when the flow reaches the line if (!_impl), the condition calculates true and goes in to update _impl, and so throws the error (the second time it runs). If instead I don't unload "module1a" the first time client (role=Customer) is logged out and then he runs again this option that loads again module1a, the if (!_impl) condition, comes false, jumps to return _impl; line, and all goes well - no error thrown.. This proves the point Alex said, but now I wonder what good is there to have a module loaded all the time just in case the client decides to run this option again.. before actually closing his browser.. I believe this defeats the purpose and I rather have to consider re-writting that "module1a" in a totally different style. I hope this is clear enough.. What is your advise ? Thank you again for helping me gaining insight in this esoteric problem.. George --- In [email protected]<mailto:flexcoders%40yahoogroups.com>, "rob_mcmichael" <rob_mcmich...@...> wrote: > > --- In [email protected]<mailto:flexcoders%40yahoogroups.com>, Alex > Harui <aharui@> wrote: > > > > See the modules presentation on my blog. That's the shared-code problem. > > Singletons need to be in the main app or a shared-code module. > > > > Alex Harui > > Flex SDK Developer > > Adobe Systems Inc.<http://www.adobe.com/> > > Blog: http://blogs.adobe.com/aharui > > > > From: [email protected]<mailto:flexcoders%40yahoogroups.com> > > [mailto:[email protected]<mailto:flexcoders%40yahoogroups.com>] On > > Behalf Of grg_blls > > Sent: Wednesday, March 18, 2009 4:37 AM > > To: [email protected]<mailto:flexcoders%40yahoogroups.com> > > Subject: [flexcoders] A ModuleLoader issue > > > > > > Hi all, > > > > I have the following problem with my current development. A client is > > loging in the system either as customer or admin and accordingly the main > > application through module manager loads either "module1" or "module2". > > If a client is logged as customer (i.e. "module1" is loaded), he is offered > > a number of choices, leading to loading one of "module1a", "module1b", etc. > > > > In every case the procedure is a unload previous/load next module through: > > > > public function createModule(m:ModuleLoader, s:String):void{ > > m.url = s; > > m.loadModule(); > > } > > > > public function removeModule(m:ModuleLoader):void { > > m.unloadModule(); > > } > > > > Finally that client is logged out when finished. > > > > Now if he does a new login as a customer, "module1" loads and offers again > > the customers options, but if he tries the same option (which leads to > > loading "module1a"), an error is thrown, with the following message from > > the Flash Player: > > > > An ActionScript error has occured > > TypeError: Error #1034: Type Coercion failed: cannot convert > > mx.managers::historymanageri...@683d219 to mx.managers.IHistoryManager. > > at mx.managers::HistoryManager$/get > > impl()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\managers\HistoryManager.as:96] > > at > > mx.managers::HistoryManager$/register()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\managers\HistoryManager.as:134] > > at > > mx.containers::ViewStack/commitProperties()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\containers\ViewStack.as:649] > > at > > mx.containers::TabNavigator/commitProperties()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\containers\TabNavigator.as:504] > > at > > mx.core::UIComponent/validateProperties()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\core\UIComponent.as:5670] > > at > > mx.managers::LayoutManager/validateProperties()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\managers\LayoutManager.as:519] > > at > > mx.managers::LayoutManager/doPhasedInstantiation()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\managers\LayoutManager.as:639] > > at Function/http://adobe.com/AS3/2006/builtin::apply() > > at > > mx.core::UIComponent/callLaterDispatcher2()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\core\UIComponent.as:8460] > > at > > mx.core::UIComponent/callLaterDispatcher()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\core\UIComponent.as:8403] > > > > Any ideas, as to the nature of it and where to look fixing? > > Thanks all in advance > > > > George > > > > Try putting this at the start of your module: > historyManagementEnabled = false; > > It worked for me, but that was with a sub application (may be the same thing). > > Rob >
