Tricks
Moving from tips to tricks, the following are facets of the tool that you may not have thought to expect.

You Can Debug Against More than Just Your Local Developer Edition of CFMX
Most debugging tools work against a local copy of whatever application you're debugging, but FusionDebug can be configured to debug code running on a remote CFML server too such as a central staging or perhaps even a production server. It could even be a remote hosted server. Of course, the server has to be configured for debugging as Jeff explains in his article so it's not a total free-for-all. Still, the feature is a two-edged sword. See my discussion of traps at the end of this article.

You Can Change Variables on-the-Fly
Don't miss the fact that the tool is for more than just watching what's happening. It also offers the option of changing the variables' values on-the-fly. While at a breakpoint or stepping through code, highlight a variable you'd like to set and right-click "Set Variable" to give it a new value. That new value will immediately be set in the currently running request.

Available Shortcuts
Besides using the mouse-based icons and context menus, there are several keyboard shortcuts available. To set a breakpoint, use ctrl-shift-b. To effect the "step over," use F6. For the "step return" command use F7, and for "Resume" use F8.

It's worth noting that the Run menu shows all the other stepping and related commands, so you don't have to use just the icons and keyboard shortcuts for stepping. This makes it clear that the debug commands used in FusionDebug are actually Eclipse commands, so you can learn more about some of these features in the general Eclipse documentation and other resources.

Though not a "keyboard" shortcut, note that you can double-click on a breakpoint in the breakpoints pane and FD will open the file at that specific line. Similarly, when at a breakpoint or while stepping, you can double-click on a file in the "stack trace" (showing the current template and line number on which execution has stopped) and that will jump to the appropriate line too. This can be especially helpful when you're several files deep (perhaps a file has called a CFC method that has done a CFINCLUDE).

Tricks in Variables and Expressions Panes
When viewing the variables and expressions panes, note that if there are a large number of items, you can use the find option to locate a specific variable. With the cursor in the appropriate pane, use ctrl-f or right-click and choose "find." Note the available wildcards, ? and *.

To set a watch expression, you can either highlight it in the editor, right-click and choose "watch expression," or right-click in the expression pane and choose "add watch expression." Finally, you can right-click on an existing expression and choose "edit expression" to change the expression.

If you want to save the value of some variable as shown in the variables pane, notice the "copy variables" option.

Manipulating Breakpoints
After working with the tool for a while, you may start to have a large number of breakpoints show up in the breakpoints pane. A nifty trick is to group them (group their display) by choosing the rightmost icon (or "view action") in its toolbar, the down arrow, and "group by," and then select a value by which to group the breakpoints. Options include grouping them by the file or project in which they appear. Another option is to create "working sets" of breakpoints that are related in some way you define. They can then be grouped by those working sets and you can move the breakpoints around to appear in those working sets.
If you wanted to remove breakpoints for reuse later, you can also right-click in the breakpoints pane and export or import them.

Available Java Detail Mode
When configuring a debug setup (as Jeff explains in the initial install and setup steps), there's an option to "Display very detailed Java information" that causes FusionDebug to interpret variables like Java objects instead. This mode is useful for Java programmers and those wanting to see the internal structure of a ColdFusion request. It's an "expert" feature, so be careful.

Traps: Challenges with Breakpoints and Stepping
Finally, I want to address several things that can trip you up. Some of them are documented in the FusionDebug manual and Web site; others are ones I've found (and since reported) myself.

My Breakpoints Don't Fire as Expected
You may have problems with how you've configured your FusionDebug setup. See the support article at www.fusion-reactor.com/fusiondebug/support-settingUpDebugConfig.html. One of the features mentioned there is an option called "Compile CF page in debug-friendly mode." This is the default but if you have a problem it would solve, you have to recompile the affected templates while you're debug-enabled. That means you need to open and change the file (even if that means just entering a space and removing it) and then save it so that the next request for the page will recompile it.

Another issue is that if you're configuring debugging against a server that's not your local machine, be careful when configuring the "web server folder" in the "connect" tab since the value for the location of the Web server files should be relative to that Web server (not relative to your local machine, such as if you use a mapped drive locally).

Another possible problem is if you set a breakpoint on a line that doesn't contain CFML tags or expressions. Eclipse won't prevent that, but execution won't break on that line.
Relative to that, the breakpoint line numbers are fixed and static. If you change the file to add or remove lines, the breakpoint line number(s) may now be incorrect, which could cause the problem above (or the breakpoint may now be on a CFML line that doesn't execute).

Still other issues are explained at the support FAQ, "Why don't my breakpoints fire" at www.fusion-reactor.com/fusiondebug/support.html#breakpoints4.

I Find That While Stepping into Some Tags and Functions It Seems to Hang
This problem happens if you use "step into" rather than "step over" on certain tags and functions and stems from CFMX's underlying implementation atop Java. Some of the CFML tags and functions themselves call on a large amount of Java code, and since Eclipse debugs Java, it will also debug the Java code underlying these tags and functions. You won't actually see the debugging. You'll just see an indication of "stepping" in the stack trace.

Related to this, some CFML tags are actually implemented in CFML so the debugger wants to debug them too. Fortunately, the tool is smart enough not to take you into such pages to debug them as explained in the support FAQ "Why don't my breakpoints fire" at www.fusion-reactor.com/fusiondebug/support.html#breakpoints4. Again, it will just show "stepping" in the stack trace, and that tag or function may take longer to run when stepping than it would when running normally.

I've seen these issues with CFDIRECTORY, CFDUMP, createobject, and findnocase to name a few. The solution for now is to simply use "step over" instead. Using "step into" really only makes sense on tags that open new files. Perhaps eventually the vendor will solve this for us.

My Attempts to Step Don't Step
There can be a couple of issues here. First, pay close attention to the stack trace pane. Again, this is the top left pane showing the file and line number on which control has stopped. If you don't see the editor reflecting control moving to the expected next line, look to see if the stack trace pane shows the control is still "stepping." This means FusionDebug is still working to run your code.

Another instance where it may not seem to be stepping is when ColdFusion MX sometimes performs optimizations around tags. Try using step into when control is on the line before the tag.

I've found an even more pernicious problem that makes stepping seem not to work. The problem exhibits itself while control is stopped on a given breakpoint. Despite subsequent requests to step through code, no new lines seem to be reached in the file editor, but if you watch the stack trace pane you see the line numbers properly stepping through the code. The problem occurs because you have opened the file using the file system rather than an Eclipse "project."

FusionDebug Is Opening the Wrong Files When I Step into New Files
The previous comment had to do with a problem created when you yourself opened a file, but FusionDebug will also open files when you're stepping through code or when it hits a breakpoint. If you find that it's opening the wrong file, see the support article at www.fusion-reactor.com/fusiondebug/support-wrongSourceFile.html.

FusionDebug Is Asking Me to Pick the Location of the File It's Opening
Related to the challenge of FusionDebug trying to open files, you have the option when configuring the source location (as Jeff describes in the setup steps) of choosing to "search for duplicates." If this feature is enabled, and FusionDebug finds more than one file of the same name in the project's folders, it will prompt you to pick which to use.

This and the previous challenge do argue for keeping your Eclipse projects as small as it can be reasonably set. As tempting as it may be to define a project at your Web site root, where you may have dozens (or more) folders or applications, the problem is that Eclipse may find many files with the same name (such as index.cfm, application.cfm, and so on).