A long while ago in developer years – sometime last year in real time – the Reflector team decided to do a spike to see if we could spice up the Reflector code pane.
At the time we were focussed on making it easier for someone to take decompiled code and understand it, in order to get to the root cause of their debugging problem. When you edit code in Visual Studio there are many tools for helping you understand the flow of data of data through the methods. Since we generate the decompiled code, we know lots of information about the code and its relationship to other decompiled methods, and so we should be able to make this information available to users of Reflector in the form of some kind of head up display.
(If you want to try it out, you can download it here)
There’s where we stopped the work, until the recent Down Tools Week where we thought we’d see if we could quickly prototype some of the functionality that we’d hoped to do. Adam, a member of the UX team helped out.
Dividing in order to conquer
This way we could quickly prototype ideas such as variable highlighting:
Or even some whacky ideas, like the one I had around labels and gotos. This used the jsPlumb library to add the graphics to the page, although the rest of the team weren’t so keen on it.
Not all browser panes are created equal (but some are more equal than others)
Of course, the browser world has been full of innovation, and browsers such as IE try to maintain backwards compatibility for pages that were written for earlier versions. They do this by offering a DOCTYPE declaration, the form of which determines the level of HTML and CSS that the browser instance is going to support.
Unfortunately it isn’t that easy for us. The embedded pane is customised in a different way, using registry entries that need to be set up by an installer. I had a quick play with this after reading this blog post and although this method seems to be used by a number of installed applications on my machine:
Despite the added entry being read by the process (according to procmon), the level of CSS support didn’t change to the desired level. Rather than spent more time debugging this, we simply opted to use jQuery to patch around the problem. This also meant that we didn’t need to rely on the user having run an installer to get the right level of support in the browser. The cost of this decision was the need to write more jQuery.
So did you get working?
We first prototyped a way to customise whether a value is displayed as hex or decimal – sometimes when you are looking at code you find that Reflector’s heuristics have chosen the wrong option, and it is useful to see the bit pattern for a decimal number when it is being used as a mask:
The second feature we added was highlighting a local variable or parameter together with all of its uses, including a sublime style map of the code so that you can see where there are other references which aren’t shown on the screen:
What did we learn?
There are bugs and design questions in the prototype which we have made available, and we’d very much like your feedback, but the work we’ve done was an interesting exercise.
By keeping the document separated into <STYLE> <BODY> and <SCRIPT> sections it was easy to transfer modified sections back into the Reflector code base. Additionally it was easy to use the F12 browser tools and their equivalents to debug the resulting behaviour.
Where can I get it?
It’s available for download as a free beta on the Red Gate labs site