Don't want to do anything big, and the only time I'd need to be in frame1 is to replace something that's already in frame 1, so it'd also be small, although the original would still be linked in as they're hard-referenced in the framework SWC. Ah, what I wouldn't give for a day with a few Player developers to pick their brains - I'm awful envious of your access sometimes, Alex :)
I know that I can expect any mx_internal stuff to change. That's what makes it fun :) And you can be sure I won't do any complaining when funky things I cook up break. Anything I release that utilises evil tricks like this will have a big *only works with SDK rev foo* label too :) FWIW, the reason I'm interested is that I'd like to wrap a few ManagerImpls (chiefly StyleSheetManager) rather than monkey-patching them, for the very reason you mention - slightly lowered chance of an updated SDK wrecking everything. Although monkey-patching would make for slightly fewer bytes, a wrapper (that only adds hooks) wouldn't be very big. -Josh On Wed, Aug 27, 2008 at 9:13 AM, Alex Harui <[EMAIL PROTECTED]> wrote: > The whole point of frame1 is to be as small as possible so we can get the > progress bar on screen. If you put some other class in frame1 that pulls > the rest of the framework in, you'll pretty much be hosed. > > > > I don't know which one you want to change, but most are in > docFrameHandler. This is undocumented territory and likely to change. > > > > *From:* [email protected] [mailto:[EMAIL PROTECTED] *On > Behalf Of *Josh McDonald > *Sent:* Tuesday, August 26, 2008 4:11 PM > *To:* [email protected] > *Subject:* Re: [flexcoders] When do all the calls to > Singleton.registerClass() happen, and can I beat it to the punch? > > > > I've been poking around inside, and it seems a few are done on frame 0 in > initialise(), and the rest on frame 1 on docFrameHandler(). > > It seems (although I haven't tested it yet) that if I sneak a class into > the first frame and call a static method on a static const assignment I > might be able to beat it, but I haven't seen any proof that you can move > classes forward in the timeline, only backward. Another on the list of > experiments to conduct :) > > -Josh > > On Wed, Aug 27, 2008 at 8:57 AM, Alex Harui <[EMAIL PROTECTED]> wrote: > > They happen early in SystemManager before [mixin], assuming the class you > want is baked into the SWF. I think CursorMgr, PopUpMgr are, but not > others. Check a link-report to be sure. > > > > To beat them, subclass SM, override mx_internal docFrameHandler and > register before calling super. One of these days, we'll clean up this > aspect of startup. > > > > *From:* [email protected] [mailto:[EMAIL PROTECTED] *On > Behalf Of *Josh McDonald > *Sent:* Tuesday, August 26, 2008 3:30 PM > *To:* [email protected] > *Subject:* [flexcoders] When do all the calls to Singleton.registerClass() > happen, and can I beat it to the punch? > > > > Hey guys, > > I can't really use Builder to do this search due to all the [ExcludeClass] > tags and such (and I don't have a builder project set up for the open source > SDK atm). Where / when are the framework singletons registered? Can I beat > it (chronologically) with [Mixin] (preferred) or calling a function in > static (smelly)? Or would it require compile-time options or > monkey-patching? > > Cheers, > > -Josh > > -- > "Therefore, send not to know For whom the bell tolls. It tolls for thee." > > :: Josh 'G-Funk' McDonald > :: 0437 221 380 :: [EMAIL PROTECTED] > > > > > -- > "Therefore, send not to know For whom the bell tolls. It tolls for thee." > > :: Josh 'G-Funk' McDonald > :: 0437 221 380 :: [EMAIL PROTECTED] > > > -- "Therefore, send not to know For whom the bell tolls. It tolls for thee." :: Josh 'G-Funk' McDonald :: 0437 221 380 :: [EMAIL PROTECTED]
