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