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, "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 flexcoders@yahoogroups.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 flexcoders@yahoogroups.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. > > > > > > > > > > > > > > > > > > > > >
