Copying Memory

I've been starting to clear some usability issues out of our backlog and ran into one that seemed simple enough but eventually required a little more thought and attention.

When debugging native code it's common to want to inspect memory so the Eclipse debug platform offers a standard Memory view. The view can host a number of memory renderings, each offering a different way of viewing a chunk of memory.

The "traditional" memory rendering is popular with C/C++ developers because it works much like the memory views in other debuggers and shows a range of memory in both binary and text formats.

"Traditional" memory rendering from CDT

Memory View in Xcode 4

Memory view from Visual Studio 2008

Memory window from CodeWarrior in 2001

 Our developer (I'll call him Tom because that's his real name) wanted to do something that seemed pretty simple: select a hex value, copy it to the clipboard, and then paste it into a variable in the Variables view. But the global "Copy" command wasn't hooked up to the memory rendering so it did nothing. Tom then discovered "Copy to Clipboard" in the context menu.

But the "Copy to Clipboard" command copied all of the selected data from the rendering: addresses, binary, and text to the clipboard so it looked like this:

0x7FFF5FBFED20  74736574 00676E69 996E019D 3CBE8497 5FBFED40                    testing...n...¾<@í¿_

Tom had to paste this into a text editor, then select just the binary/hex part, and finally had something to paste to set the value of his variable. This sort of thing delights some people because they find a work-around and then have another story to inflict on their colleagues, but Tom had real work to do, expected better, and logged a bug. Our team worked on other stuff that seemed more important until last week when I went back to take another look.

First I looked to see if the rendering's support for "Copy" could just do the right thing by grabbing the address, the binary data, or the text based on which part had been clicked in last. While that would work in the narrow case it wouldn't leave any indication of what it might do if you have forgotten which area you clicked in last, and the ability to copy all three (addresses, binary, text) would have been lost.

There needed to be a more explicit way to say which portion of the data you wanted to copy. So I changed the context menu to provide all four options.

This would make life better for Tom but still wouldn't fix the "select the hex data and hit control/command - c" scenario. So it also keeps track of one choice as the default option that is used when fired by the global "Copy" command, which is now hooked up to the rendering. Tom will have to select "Binary" once and then Copy will work the way he expected.