flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wayne Studley <waynestud...@me.com>
Subject Re: tracking down where "[trace] null" statements are comming from?
Date Wed, 23 Jan 2013 22:20:49 GMT
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, "christofer.dutz@c-ware.de" <christofer.dutz@c-ware.de> 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:gosmith@adobe.com] 
> Gesendet: Mittwoch, 23. Januar 2013 19:02
> An: users@flex.apache.org
> 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:aharui@adobe.com]
> Sent: Wednesday, January 23, 2013 9:56 AM
> To: users@flex.apache.org
> 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" <gosmith@adobe.com> 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:montoyland@gmail.com]
>> Sent: Wednesday, January 23, 2013 4:02 AM
>> To: users@flex.apache.org
>> 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, "christofer.dutz@c-ware.de"
>> <christofer.dutz@c-ware.de> 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:omarg.developer@gmail.com]
>>> Gesendet: Mittwoch, 23. Januar 2013 11:00
>>> An: users@flex.apache.org
>>> Betreff: Re: tracking down where "[trace] null" statements are comming from?
>>> 
>>> On Wednesday, January 23, 2013, christofer.dutz@c-ware.de 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
> 
> 


Mime
View raw message