I assume the trace() is coming from your code and not from the Flex SDK. Correct?
I have a tendency to use className in my traces to make sure I know where output is coming from: trace(className + ": someVar value: " + someVar); This approach may be too OG for you, but I thought it might help. Leif Leif Wells Atlanta http://www.linkedin.com/in/leifwells On Wed, Jan 23, 2013 at 4:17 PM, Wayne Studley <[email protected]> wrote: > 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 > > > > > >
