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 > > > > > > > > > > > > > > >
