I don't think the compiler knows anything special about trace(); I think it just finds it in playerglobal.swc. But the fact that it is 'native' may explain why you can't monkey-patch it. You can't override it because it isn't a virtual method of a class, it's a package-level function.
- Gordon -----Original Message----- From: David Coleman [mailto:[email protected]] Sent: Wednesday, January 23, 2013 1:49 PM To: [email protected] Subject: RE: tracking down where "[trace] null" statements are comming from? yeah, jude, I've tried that override the trace trick... no dice. trace is a low level keyword > From: [email protected] > Date: Wed, 23 Jan 2013 15:44:22 -0600 > Subject: Re: tracking down where "[trace] null" statements are comming from? > To: [email protected] > > Yeah, Search in Files (CTRL + H in Eclipse) is what I ended up doing > in a similar situation but I had access to all the libraries. > > It's also a good idea to use TraceTargets, although I haven't used it > until relatively recently. They let you control the destination of > trace statements, the level of information (debug, info, error, etc), > along with source of the call, timestamp and so on. > > Maybe in the next Flex SDK we can override trace (or create an > alternative like "console") to point to an Application or > SystemManager level trace target. > > > On Wed, Jan 23, 2013 at 3:30 PM, David Coleman < > [email protected]> wrote: > > > yeah Wayne is right, and another option that *I* find particularly > > useful is go get the source code for your libraries and copy it into > > your src folder. then you only link to the code that you need. You > > don't use any more space than you would with a pre-compiled swc (in > > fact you may use less). AND you have access to all the black magic > > voodoo that your libraries might be doing. In this way it ceases to > > become voodoo and becomes your code to tweak and polish to meet your > > specific needs. There are no real licensing concerns with this > > approach since using the swc in the first place already places you > > in a position of dependency on your eula for that particular package. > > > > This way you can do as Wayne suggests and simply search for the > > trace in the code and comment it! :-) And you now have full a-z > > control over your application's code. Two birds, one stone = 1 happy > > developer. > > > > > Subject: Re: tracking down where "[trace] null" statements are > > > comming > > from? > > > From: [email protected] > > > Date: Wed, 23 Jan 2013 21:17:55 +0000 > > > To: [email protected] > > > > > > Quick question - are your components linked swc's / ane's etc or > > imported classes (as in a bunch of .as files)? > > > > > > If it's the latter you can use a tool like EasyFind (for Mac - no > > > idea > > what a PC equivalent is) to search inside the files for any 'trace' strings. > > > > > > If the components are compiled swc's then you're going to have a > > > tough > > time omitting the trace but I'm guessing it'll be somewhere in an > > imported .as file. > > > > > > Hope this helps? > > > > > > Wayne > > > > > > On 23 Jan 2013, at 21:00, "[email protected]" < > > [email protected]> wrote: > > > > > > > Gee ... I really hoped this would work, cause it looked like the > > > > type > > of AS voodoo I was hoping to find. > > > > So I created a file "trace.as" and pasted in your code. IntelliJ > > jumped to the right place, but the breakpoint was not hit. > > > > In order to try if defining functions this way worked, I added > > > > the > > same function (called "lalala" in a file called "lalala.as") and > > called both functions from initializing code ... lalala was hit, trace > > wasn't ... > > so I guess this hack was a good idea, but it didn't work :-( > > > > > > > > Decompiling is problematic, as the Flexicious components have a > > > > copy > > protection and decompiling that code would result in me losing my > > license ... I don't want to risk this after paying that much money > > for it ;-) > > > > > > > > Well I think I'll simply live with the trace statements :-| > > > > > > > > But thanks anyway, > > > > Chris > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: Gordon Smith [mailto:[email protected]] > > > > Gesendet: Mittwoch, 23. Januar 2013 19:02 > > > > An: [email protected] > > > > Betreff: RE: AW: tracking down where "[trace] null" statements > > > > are > > comming from? > > > > > > > > Isn't trace() is just a public function in the unnamed package? > > > > I'd > > try putting a file with > > > > > > > > package > > > > { > > > > public function trace(...args):void > > > > { > > > > var i:int = 0; // set breakpoint here > > > > } > > > > } > > > > > > > > on the source path. Then mxmlc should find this trace() instead > > > > of the > > trace() in playerglobal.swc. But I've never tried monkey-patching a > > non-method, or anything that is native. > > > > > > > > - Gordon > > > > > > > > > > > > -----Original Message----- > > > > From: Alex Harui [mailto:[email protected]] > > > > Sent: Wednesday, January 23, 2013 9:56 AM > > > > To: [email protected] > > > > Subject: Re: AW: tracking down where "[trace] null" statements > > > > are > > comming from? > > > > > > > > I'm not sure how to do that. > > > > > > > > But consider this: When the flex tool chain creates a SWF in > > > > release > > mode, it cleans out trace statements, so whatever is spitting a > > trace has debug code in it. The swfdump decompiler will certainly > > show you what SWFs have debug code in it. > > > > > > > > Then, I generally use divide and conquer by placing breakpoints > > > > and > > seeing if the flashlog.txt has the trace in it. But once you get to > > a "reasonable" > > > > boundary around the area, you can also use the poorly documented > > flash.trace.Trace to dump all function calls leading up to the trace > > statement. > > > > > > > > On 1/23/13 9:48 AM, "Gordon Smith" <[email protected]> wrote: > > > > > > > >> Is it possible to monkey-patch trace() to substitute your own > > > >> version, and set a breakpoint in it? > > > >> > > > >> - Gordon > > > >> > > > >> -----Original Message----- > > > >> From: Michael Montoya [mailto:[email protected]] > > > >> Sent: Wednesday, January 23, 2013 4:02 AM > > > >> To: [email protected] > > > >> Subject: Re: AW: tracking down where "[trace] null" statements > > > >> are comming from? > > > >> > > > >> Hey Chris, > > > >> > > > >> This may be a long shot, but how about using a an swf > > > >> decompiler? I remember ising Trillix awhile back and was very > > > >> impressed by the amount of detail provided in the diagnostics - > > > >> It may pinpoint the source of your trace statement... > > > >> > > > >> Cheers! > > > >> > > > >> On Jan 23, 2013, at 11:46 AM, "[email protected]" > > > >> <[email protected]> wrote: > > > >> > > > >>> Hi Omar, > > > >>> > > > >>> thanks for that input ... I knew that "trace" is a Flash > > > >>> function. I was simply hoping for some guru here to give me a > > > >>> hint to the "ultimate way to debug this" ;-) As it would help quite a > > > >>> lot ... > > > >>> especially when having AMF serialization/deserialization > > > >>> problems (The other type of problems that seem to be really > > > >>> hard to debug) > > > >>> > > > >>> Chris > > > >>> > > > >>> -----Ursprüngliche Nachricht----- > > > >>> Von: Omar Gonzalez [mailto:[email protected]] > > > >>> Gesendet: Mittwoch, 23. Januar 2013 11:00 > > > >>> An: [email protected] > > > >>> Betreff: Re: tracking down where "[trace] null" statements are > > comming from? > > > >>> > > > >>> On Wednesday, January 23, 2013, [email protected] wrote: > > > >>> > > > >>>> Unfortunately I can't set a breakpoint to the "trace" function ... > > > >>>> perhaps it would be good if in future versions of flex there > > > >>>> would be the means to somehow do this. > > > >>>> > > > >>>> Chris > > > >>> > > > >>> The trace() function is not a method from Flex it comes from > > > >>> Flash > > player. > > > >>> There really isn't anything that can be done at the Flex level. > > > >>> > > > >>> I would try to get source code for your 3rd party libraries > > > >>> and search for trace statements. If the source isn't available > > > >>> then you're probably out of luck. Or you can try a decompiler. > > > >>> > > > >>> Also, I don't know enough about Adobe Scout but maybe that > > > >>> could help you narrow it down. > > > >>> > > > >>> -omar > > > > > > > > -- > > > > Alex Harui > > > > Flex SDK Team > > > > Adobe Systems, Inc. > > > > http://blogs.adobe.com/aharui > > > > > > > > > > > > > > >
