The Debugger tag allows debugging your Mate code (EventHandlers and sub-handlers blocks, MessageHandlers, etc). When using this tag, you specify a level of debugging, which will filter the type of messages you see.
It is recommended that you remove this tag from your code when you are ready to deploy. Its use during production will impact performance if you enabled the debugging in many objects (ie: in many EventHandlers) or if you specified a low debugging level such as ALL or DEBUG.
<mate:Debugger level="{Debugger.ALL}" />
Attributes
level
int
Provides access to the level the debugger is currently set at. Value values are:
- Debugger.FATAL: designates events that are very harmful and will eventually lead to application failure
- Debugger.ERROR: designates error events that might still allow the application to continue running.
- Debugger.WARN: designates events that could be harmful to the application operation
- Debugger.INFO: designates informational messages that highlight the progress of the application at coarse-grained level.
- Debugger.DEBUG: designates informational level messages that are fine grained and most helpful when debugging an application.
- Debugger.ALL: intended to force a target to process all messages.
1a. Can you explain how badly will performance be hit if these tags are not removed before deployment?
1b. If I use a level of ERROR, and no log output is produced, then do I still get the same performance hit as when this tag commented out or removed?
2. Is there an easier way to turn them on/off either at runtime or before compiling? ie. instead of removing all such tags. eg. consider debugging of a stable code branch with 5 or say 10 event maps.
If you only have it set to show errors, then the impact will probably not be too big.
You can also have only one Debugger tag in the main Application file, instead of one per event map. That would make it easier to remove when creating the production swf.
I am a mate newbie-... so be patient.
I have just made a small example using the stpckQuotes example as template.
My issue is that look like eventMap do not collect my event and I cannto see debug info in any place.
I do not see any debug panel or similar.
Event eclipse console do not show nothiing ...
Any suggestion??
Thanks
Andrea Campolonghi
1) FB3 console only displays trace() output if you run the program in debug mode.
2) You need a debugger tag at the event level of your map, or "higher" up the display list if you have many.
3) The tag objects (and their children) you wish to debug have to have their property debug="true".
4) The activity you want to see debugger output has to actually happen. eg. For EventHandlers, the correct Event() type value being dispatched and listened for. btw "type" is a silly property name IMO. It's really the event name string. Event class type only matters when passing data as event object properties.
5) Lastly, and getting off topic for this Mate tag - if your app has many components, then you need to understand Flash/Flex event flow. Things like bubbling and the concepts of listeners and dispatchers.
In addition to what Emmet said, I would suggest to make sure that the bubbles property of your event is set to true.
yes. That was the issue. I forgot to leave event bubbling....
Now is working and .... good job.
Bye
Andrea
A very simple method call with 2 arguments is giving me this message, and I'm curious as of under what conditions the debugger is unable to give a meaningful response (so I can avoid them if possible).
The best is to use the Debugger tag in the main application, then remove it during production.
Andres,
That may happen if there is an error in the code you call, but I am not sure why it doesn't show you the whole error.
I'm sorry that I wasn't clear enough - the code I'm calling is behaving as expected, but the debugger was reporting "Cannot debug". I later figured out what was happening:
I was testing a method invocation with explicit values (ie: 5, 10), but after I replaced those with variables the debug tag started to work. While I would never use explicit values in real code, it was confusing for a while. So, for anybody reading this, magic numbers for arguments make the debug tag unable to give any meaningful trace.
<a href="http://askmeflash.com/applications/9/runtime-flex-tracer-and-debugger">http://askmeflash.com/applications/9/runtime-flex-tracer-and-debugger</a>;
I am trying to improve the performance at the same time allow for development to easily enable and disable debugging. I thought that the Debugger tag would allow this but after removing all the debug attributes and only have one Debugger tag it does not seem to show any debug output on my console even if I have Debugger.ALL set.
So the question is... How is the attribute level debug="true" related to the overall Debugger tag and what is the best stratagy to provide both a way to disable it in production and enable it for development. One way I thought was to have a debug attribute for each event map that binds to each map configuration tag allowing to turn on/off debug on a map basis or is that also a no no from a performance point of view.
Your guidance would be most helpful here.
The overall Debugger tag is needed to turn debugging on and off globally, but each set of handlers that you want to actually debug need to have debug=true. The ALL attribute for the debugging tag relates to the debugging level and not to which tags are debugged.
If you put debug=true to all or any EventHandler that you want, removing the Debugger tag will effectively removing debugging completely.
For final code, I normally only put debug=true where I need it at that moment, and then remove it when I don't need it any longer. I do the same for the overall Debugger tag. When you have several maps and lots of events, it doesn't make sense to leave debug=true hanging around because when you enable debugging with the Debugger tag, you get a lot of output in the console that will probably be just confusing.
Ron