Home

Whosawhat now?

DConsole is a box of utilities for interacting with your Flash application at run time, primarily taking the form of an output textfield and an input textfield. The output field doubles as a trace window, and is your source of feedback. The input field is how you primarily interact. You type in commands, built-in or custom, and watch the effects take place.

It works by sitting on top of the rest of your application, crawling your ActionScript objects, their properties and children, and letting you change their variable values, call methods and so forth. It also allows you to quickly write reusable plugins, that can go from simple collections of utility commands, to custom level editors or whatever else you may require.

How do i implement it?

A singleton utility, DConsole, lets you access and write to the console from anywhere in your application, as well as link methods to custom console commands for testing with various arguments. To get started, simply addChild(DConsole.view) at your root, and you're off.

Won't it mess around with the rest of my application?

Absolutely. That's what it's designed for! Only when you ask it to, though.

Is it deploy ready?

It constitutes a pretty serious security risk, allowing end users intimate access to the application data. Removing it from distributed apps is a good idea, unless you want to offer your users that sort of functionality. It is blockable behind a pass key should you desire it.

What constitutes a "command"?

A command is simply a bit of text pointing to an action you want to carry out. For instance, typing in "clear" and hitting the enter key will clear the console message buffer, removing all its content. Custom commands are awesome.

But I hate typing!

The console incorporates fast, aggressive auto-complete for object names, commands and properties, as well as a persistent command history maintained through a shared object, accessed with the up and down arrow keys. You will love this when you need to test series of commands you already put in the previous session.

I still don't get it. Why?

If you don't "get it", then it's probably not for you in the first place. Go on, then! Live your life! Here are examples of ways in which I've used it to date.

• Trying various image URLs with an image gallery to see if scale and layout automates correctly
• Passing arguments to a socket connection to test connectivity and remoting
• Adjusting tween times alongside an AD without having to recompile
• Adjusting pixel position, rotation and scale of display objects alongside a designer without having to recompile
• Changing game agent states at runtime to test various conditions
• Changing application states under various conditions to make sure it doesn't break
• Reloading site XML content descriptors at runtime, letting me compare documents and make changes to documents without having to recompile to test them.

Bring your skills to the battle!

This is more of a canvas than a truly complete tool. You need to add commands yourself to make it truly useful. Also, by its nature, this is not a particularly intuitive tool. You type in words to execute commands, and it requires a developer's understanding of a Flash application. Designers will hate it. For most users, this is not a fast way to work. However, if you are working on medium sized applications, and need to test things like multiuser functionality, remoting, game behaviors or otherwise need a frontend with which to interact with your application without having to put big temporary buttons on your stage, this is where it's at.