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