First off: THANK YOU! I completely missed out on this feature. It seems
already doing half of the job necessary.
I will take a quiet hour on the weekend to investigate int
version/platform availability.
But, Just half of the job means:
It seems as if the arguments get converted to a string which would be a
no-go. The line number is a good thing, but
the container type would be a more helpful for proper and consistent
filtering. Also it is not possible to implement a "isEnabled" flag,
which is essential for logging in big systems.
To sum it up: Nice thing, I will definitely get into it, but from what I
can judge right now, it is not enough to implement a clean, fast logging.
yours
Martin.
On 20/01/2012 23:43, Dirk Eismann wrote:
I just researched the flash.trace.Trace class Alex mentioned and found
http://blog.sangupta.com/2011/08/magic-of-flashtracetrace.html
which was blogged by Sandeep (who is on this list as well).
A quite interesting (undoc'ed) feature that might be handy but I guess
this is a debug runtime / debug build feature only.
Dirk.
2012/1/20 Dirk Eismann<bort...@googlemail.com>:
I like the idea. I often wished we had logging capabilities for
release version SWFs running in release players that are similar to
what e.g.. log4j offers for Java applications (the reason it works in
Java is that javac by default always compiles debug information for
source files and line numbers into class files. They have no concept
of a "release build" vs. a "debug build". Different VM, different
features)
The use case Martin describes (error only happening in release player
or only on specific machine configurations usually at the end user /
customer) sounds too familiar. The way I handled this was to add some
self crafted logging that accumulates log information and on demand
sends them away using http... not nice, but works. But it also could
be so much better.
So I definitely would like to see these logging features Martin
sketched up and would be happy to help out.
Dirk.
