Question: Which is more useful to you?


1. A native trace solution

FlashDevelop handles native trace messages when you test your project, or browser plugins like FlashTracer output your trace messages after setting up mm.cfg and tailing flashlog.txt on your machine.

2. A standalone debug solution

Standalone debug solutions like Xray, Alcon or FlashDevelop's FlashConnect class use LocalConnection and send messages outside the player. You gain extra features but can no longer use trace() directly.


If you like the native trace solution:

Would you prefer to have a browser plugin or would you prefer to have a standalone application?
Technically speaking, how does FlashDevelop capture Flash's trace messages without using a custom class or flashlog.txt?


If you like the standalone debug solution:

Do you like using a standalone application, or would it be more useful if your debugger could be accessed as a browser plugin?


Thanks guys!

I've used Xray, FD's native tracing, and "MX" tracing via the debug player. Amongst them all, I'm leaning towards the native tracing. The biggest issue is if I have a web-page up (e.g., Pandora) that has trace messages still in the Flash file being played. (Aside, I think there is a "2600:Hacker's Quarterly" article to be written about a FD setup and surfing web-site that have traces still output in their SWFs.)

I wish the native trace function would work out of the box; I've set them up +3 times and it's a bit of a pain. (Which is why I added the instructions in the Wiki.) Tracing is done at work (AAA video game) for large AS2 based projects that are tested in Flash and in Scaleform's own player, tracing at home is for AS3 projects only run in Flash.

Xray is a powerful debugging tool, and I've played with it... but something about how it "feels" is why I don't utilize it in my own pipeline.

elyon: Interesting questions; planning something?

I'm using native tracing - so they are captured in FD automatically and I can see them in Firefox using FlashTracer.

I feel XRay is not simple enough to include in a projet, but the DOM exploration feature is certainly interesting (I wouldn't use it for tracing).

I personally prefer to use native tracing when I am developing a project. However, configuring mm.cfg to prompt Flash Player to output flashlog.txt seems unnecessarily complicated to me, and is a pain to set up -- especially if you are on a computer other than your own.

The only alternative that I know of is to use LocalConnection to send out my own trace messages. However, this requires the use of a custom class and the breaking of my personal habits of typing trace instead of Output.trace or whatever the class is called. However, if this class detected whether the SWF is being played locally or in a browser, and called trace or LocalConnection depending, then perhaps this would be reasonable enough.

If I was to use LocalConnection, I could capture the trace messages either in a browser widget or it could be a standalone debugger running as an AIR application. However, if I go so far as to do that, I'm heading into territory of existing debuggers that may do a better job of profiling and tracing than what I might want to build -- a simple trace window.

I don't use Firefox and its a pain to open it for FlashTracer or to install an application on my machine to tail flashlog.txt -- again, especially when I'm at a client's office when they are seeing an error I want to debug.

All this spoken, does it sound as if a simple class to output into a browser widget or a standalone app would be useful, or would it be reinventing the wheel? Or do you feel that configuring mm.cfg and capturing native traces is the way to go, and that I should really just put up with it?

What about to build an installer for the native tracing with flashdevelop plugin with it? Run and install with no other worries. Or even make that fdtracer to a small standalone app?

Mika: Personally I like the integration of fdtracer... plays well with an environment I know; less windows to eat up my desktop, tooltip bar, and/or screen space.

Just started checking out Alcon, great screen shot... but doesn't seem to work (at least with AS2 projects.)

I think the best and the easiest option would be to build an installer that does the configuration and installs Firefox plugin and/or FlashDevelop plugin (FDTracer).

Thanks for the reference. I wasn't using FDTracer -- I just installed it and it works a lot better for me that the other native trace solutions I had been using.

However, I'm still thinking that I may venture into creating my own tracer using LocalConnection. Maybe. Having FDTracer is really helping.

The worst part is that I would have to break away from typing trace, and I would have to include an extra class. However, the upside is that I could create a companion SWF which receives the trace messages, and I can package that SWF into whatever form is most useful to me. For example, a browser sidebar, a browser widget, a website or an AIR application. If a client is experiencing weird problems, I could ask them to browse to my logger in another browser window, and tell me what messages showed up. This would let me capture this vital information without asking them to set up mm.cfg or hunt down flashlog.txt. Plus, most of the design agencies I work with are all using Macs anyway.

My key would be to have what we all know and love: a simple, useful, output window. That would be more useful to me than a schmancy swiss army knife SWF debugger tool.

Would anyone else be interested in a tool like this? I probably would add support for message coloring and other common features for an output window. I could also instruct the class to continue to output traditional messages (in case you prefer FDTracer or FlashTracer) but still add extra functionality (like making it easy to throw errors, or identifying the class which is reporting the message ... such as "[MyMainClass] Trace message" rather than "Trace message")

I should mention that FD includes a tracing class not based on the usual LocalConnection/Socket solutions.

That's org.flashdevelop.utils.FlashViewer and it's based on fscommand (basically it calls: fscommand("trace", msg). So it's great when you run inside an HTML page for instance, and I guess a Firefox extension could capture these messages like FlashTracer does.


Still I think what we really need to make things simple would be a tool to automatically download, install and configure the Flash debug players, the Flex SDK, etc. It could be like a "diagnostic tool", showing current FD & system configuration about Flash IDE, Flash players, Flex SDK, Java runtime,... and allowing for automated configuration.

Can Flex and Flash Player be distributed without paying any fees?

Theoretically if someone were to lead users through configuring Flex, Flash Player, and Java, it might make sense if it were built into FlashDevelop's installer, or if there were some kind of prerequisite installer.

I don't work with installers so I'm not sure if it would be a difficult idea to execute. Basically you auto-detect if they have Java installed, Flash installed, Flash Player, the Flex SDK and mm.cfg, but you give users the option to hand-pick these paths, opt-out of writing mm.cfg, and provide links for them to download any of the missing pieces.

However, I don't think this process is all too complicated so long as people know where to download everything.

I fear most of these softwares can not be redistributed. It's better to automate their download and installation.

I did a quick and dirty installer for enabling native tracing (installs config and log files) and also optionally installs FlashTracer for Firefox. Please test it out and let me know if you have ideas to improve it.

http://www.flashdevelop.org/downloads/r ... -1.0.0.exe

P.S. It also enables policy file logging but FlashTracer isn't following it.

With FDTracer installed, I started receiving errors today when I would try and create a new class file. After the error, FDTracer didn't seem to follow what was going on under flashlog.txt.

Has anyone else experienced this behavior before?

If I remember right, the message paid mention to not being able to cast a DataEvent as a TextEvent, then the new class was created without having any of its variables replaced with the real values.

There were some changes that we did to the events that broke some of the current 3rd party plugins. With RC1 we locked the PluginCore so plugins should be compatiple from here on. They just need to be rebuilt against the RC1.