@Wayne: Actually not ... if you purchase the "Unlimited Domain & Source License" package for about 2000$ then you also get the code ... I guess you understand why I don't want to lose the license ;-)
@Justin: Well that only helps if you write the code ... if the 3rd party lib doesn't use it, you're still stuck. @All the others: Well I have decided to actually ignore the statements as it seems that the effort of tracking down where they come from is far too complicated compared to the benefit of not having the statements output. I was just hoping for a magic trick by one of you guys here. But it seems there is no such trick :-| Thanks anyway :-) Chris -----Ursprüngliche Nachricht----- Von: Wayne Studley [mailto:[email protected]] Gesendet: Mittwoch, 23. Januar 2013 23:21 An: [email protected] Betreff: Re: tracking down where "[trace] null" statements are comming from? Further from my earlier suggestion - I've just had a look at the Flexicious site and I'm guessing these guys don't provide the source code given their $999.99 price tag (and I've not enough change in my pockets to try it out). I'd assumed it was a github/google-type repository that you could grab the source. Try sending the developers a nice email suggesting that their tried & tested datagrid shouldn't need any debugging/tracing means - that should work! On their site there's also an option to purchase the source code I see - that'd sort you out (if you've much deeper pockets that I!) - but why you'd spend any more that the grand you've already forked out for the sake of omitting a 'null' trace I'd love to hear. W 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 > >
