flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jude <flexcapaci...@gmail.com>
Subject Re: tracking down where "[trace] null" statements are comming from?
Date Wed, 23 Jan 2013 21:44:22 GMT
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 <
david_coleman_007@hotmail.com> 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: waynestudley@me.com
> > Date: Wed, 23 Jan 2013 21:17:55 +0000
> > To: users@flex.apache.org
> >
> > 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, "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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message