Oh yeah one more thing.
I know why they did this. At least a perspective.
If you have version 2.0 linking in ManagerA and they change the
implementation to ManagerB in 2.5, ManagerA will not be linked in unless
ManagerA is linked, other wise ManagerB is linked in, in 2.5 and the string
decouples the dependency of ManagerA in the last version.
may be wrong here but it makes sense to me.
Peace, Mike
On 2/7/07, Michael Schmalle <[EMAIL PROTECTED]> wrote:
Hey,
Don't get me wrong here but, what happens when you use
getClassDefinition() and you didn't link in your class as a static
dependency?
Same error as you get here.
Is it a flaw or a chicken and egg thing like 'my computer can't entirely
think for me' thing.
Peace, Mike
On 2/7/07, Bjorn Schultheiss <[EMAIL PROTECTED]> wrote:
> Yo Z,
>
> Each Manager is registered as a singleton.
> code excerpt;
> Singleton.registerClass("mx.managers::ICursorManager" ,
> Class(getDefinitionByName("mx.managers::CursorManagerImpl" )));
> Singleton.registerClass ("mx.managers::IDragManager",
> Class(getDefinitionByName( "mx.managers::DragManagerImpl")));
> Singleton.registerClass( "mx.managers::IHistoryManager",
> Class(getDefinitionByName( "mx.managers::HistoryManagerImpl")));
> Singleton.registerClass("mx.managers::ILayoutManager ",
> Class(getDefinitionByName("mx.managers::LayoutManager ")));
> Singleton.registerClass("mx.managers::IPopUpManager" ,
> Class(getDefinitionByName("mx.managers::PopUpManagerImpl" )));
> Singleton.registerClass( "mx.styles::IStyleManager",
> Class(getDefinitionByName( "mx.styles::StyleManagerImpl")));
> Singleton.registerClass("mx.managers::IToolTipManager ",
> Class(getDefinitionByName("mx.managers::ToolTipManagerImpl ")));
>
> It's quite interesting in the way they implemented this process but i do
> believe that this particular bug has exposed a flaw in their decision.
> The problem seems to be is that these singleton's are not getting
> registered if they are not being used. this is generally a good thing until
> the introduction of modules where the child parent relationship exposes the
> flaw.
>
> Anyway at-least we've got a fix.
>
>
> regards,
>
> Bjorn
>
> On 08/02/2007, at 5:07 AM, zenwarden wrote:
>
> I can't test the fix because I cannot replicate the bug. It has
> mysteriously vanished...The next time I see it, I will try the
> suggested fix and report back.
>
> Also sorry if I ranted in my last post. Just don't like to see any
> problems with my new favorite technology.
>
> --- In flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com> ,
> "zenwarden" <[EMAIL PROTECTED]> wrote:
> >
> > I will give it a try.
> >
> > One question and one comment:
> >
> > Question: Did you actually mean drag manager or did you mean History
> > manager? (I'll try both sperately).
> >
> > Commnet: I've been a virtual evenagilist for flex at the company I
> > work for; I am very impressed with product and love using it. But this
> > does make me a bit nervous. I'm also really hoping that what you are
> > sayimg about singletons is not true. Singletons should never be used
> > liberally like this. It's a lazy solution to resource mamnagemnt
> > issues. The whole point of design patterns is (in my humble opinion)
> > to solve an EXISTING problem. You don't use a singlton because you
> > can, or because it's neat or even because you think it will be
> > effecient or cleaner --- you use a sington (and any pattern) after
> > you've identified a problem.
> >
> > The flex team needs to stop reading design pattern book.
> >
> > To sum up: you can always tell what chapter in gang of four a coder is
> > reading, its the pattern they are sticking into all their code :)
> >
> >
> >
> >
> >
> >
> >
> >
> > --- In [EMAIL PROTECTED] <flexcoders%40yahoogroups.com> ups.com,
> Bjorn Schultheiss
> > <bjorn.schultheiss @> wrote:
> > >
> > > Here's a reply i got from one of the engineers, Alex Harai on what
> > > could be a related issue.
> > >
> > >
> > > This error occurs for two reasons: One is that somehow, the
> > > DragManager or DragManagerImpl is not linked into the movie.
> > >
> > > The other, and more common reason is that more than one module is
> > > using the DragManager, but the main application does not.. Modules
> > > operate in their own application domain, and thus cannot share
> > > singletons unless that singleton is loaded by the parent application
>
> > > domain. The simple solution is to link the DragManager into the
> main
> > > application by putting something like this in a script block
> > >
> > > import mx.managers.DragManager;
> > >
> > > var dm:DragManager;
> > >
> > > This fattens your application a little. More complex solutions
> > > involve loading the DragManager into the main application's
> > > application domain.
> > >
> > > The above is true for all managers handled by Singleton and lots of
> > > other shared classes in Flex as well.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On 06/02/2007, at 11:49 AM, zenwarden wrote:
> > >
> > > > I am seeing this mostly when I run unit test using the
> flexunit.swf.
> > > > And I am consistantly seeing it in that situation
> > > >
> > > > I do occasionaly see it when running a single-swf app through the
> > > > builder (However it is making a connection to a server when it
> > > > occurs).
> > > >
> > > > Chris W
> > > >
> > > > --- In [EMAIL PROTECTED] <flexcoders%40yahoogroups.com> ups.com,
> Bjorn Schultheiss
> > > > <bjorn.schultheiss @> wrote:
> > > > >
> > > > > does your app use modules, or built using multiple swfs?
> > > > >
> > > > >
> > > > > On 06/02/2007, at 5:49 AM, zenwarden wrote:
> > > > >
> > > > > > There appears to be a failry serious bug that I think was
> > > > introduced
> > > > > > in the history manager in the latest release 2.0.1
> > > > > >
> > > > > > I never got this errro until I updated and I now see it in a
> > > > variety
> > > > > > of situations (including whenever I run testcases. )
> > > > > >
> > > > > > Shutting down the borwoser or even switching borwsers does NOT
>
> > > > help. I
> > > > > > mostly see it when I am running from the flex builder, but
> when
> > > > you
> > > > > > are trying to run tests -- this becomes failry serious and
> very
> > > > time
> > > > > > consuming.
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
>
>
>
>
--
Teoti Graphix
http://www.teotigraphix.com
Blog - Flex2Components
http://www.flex2components.com
You can find more by solving the problem then by 'asking the question'.
--
Teoti Graphix
http://www.teotigraphix.com
Blog - Flex2Components
http://www.flex2components.com
You can find more by solving the problem then by 'asking the question'.
