Products, the Universe and Everything

The Riverblade Developer's Blog

Beth demonstrating Visual Lint at the ACCU Conference 2008  Anna taking part in a discussion panel at the European Software Conference 2007 

Welcome to our developer's blog. We hope that this forum provides an insight into us, our products and how we develop them. Please feel free to write to us if you have anything to add to any of the posts here.

Current Entries | Archives |

A first look at a rather useful display in Visual Lint
Friday, January 28, 2005

The Visual Lint Warning Lookup Display
The display allows the user to view details of any warning by category

Every so often in the development of a product you have one of those wonderful "Yes!!!" moments., and we are certainly no exception.

Our most recent one came on Thursday evening, when one of the displays we'd envisaged for Visual Lint came together and began to show its full potential.

It's actually a very simple idea, and closely related to the concept of "Dynamic Help" introduced in Visual Studio .NET - a tool window which displays information on a specified warning. This is particularly useful since many PC-Lint warnings which are likely to be unfamiliar, and repeatedly referring to the manual to find out what lint "error xxx" means is time consuming and unproductive.

When we've needed to do this we've tended to load up the PC-Lint manual (a PDF file) and used the "find" function to find information on the warning we were seeing. However, even with the ability to view the manual within the Visual Studio IDE provided by the add-in, it's a bit of a laborious process.

A short while ago we had an idea of how to overcome that, and it all starts with a text file called msg.txt which is supplied with the PC-Lint installation. It struck us that if we could parse that file and convert it to a searchable database, we could write a toolwindow which allowed the user to look up information on a specified warning, without recourse to the manual. Beth's speciality is database design, so this was an ideal opportunity to bring her skills to bear on the project too. While I designed and implemented the user interface, she did the same for the parser and database which are critical to the operation of the display.

We started putting the two together earlier this week, and the result is everything we'd hoped for, as I hope you can see from the images on the right.

Using this display a developer can either browse warnings by category (the section numbers for which correspond to those in the PC-Lint manual), or enter a warning number manually and look up its definition.

That's pretty useful in itself, but what if we could integrate it in such a way that double clicking on a warning in the Output Window would not only jump to the corresponding line in the source file, but also show the definition of the warning in our toolwindow? Not that would definitely be useful!

Time to do some research. However, although we found we could intercept commands such as "Edit.Goto Next Location" (F8 by default) simply enough by implementing the BeforeExecute() and AfterExecute() command event handlers, we just couldn't find any way to intercept double click events in the Output Window, and were coming to the conclusion that we'd have to walk the window hierarchy (using Win32 directly) and hook or subclass the window.

A query I posted to the vsnetaddin Yahoo Group and the microsoft.public.vstudio.extensibility newsgroup (on server if you're looking for it) describes the problem and how we thought we might have to address it:

    We're developing an add-in which needs to catch events in an associated pane in the output window, which contains Lint warning information relating to the code. As you'd expect, double clicking on a line in the pane will jump to the corresponding line in the code.

    So far so good. However, we also have a corresponding toolwindow which displays details of a selectable warning. We'd like to link this to the output window so that double clicking on a warning in the output window will not only open the corresponding line of the source, but also show details of the corresponding warning in the tool window.

    Studying the automation model, catching the command events BeforeExecute() and AfterExecute() looks like it will do the trick. A little ferreting around in the debugger reveals that the "Go to Error/Tag" command on the context menu of the output window is nameless, but has GUID {5EFC7975-14BC-11CF-9B2B-00AA00573819} and ID 319. There are other commands which have the same effect (e.g."Goto Previous Location" and "Goto Next Location"), but doubtless we can catch them the same way.

    However, we haven't been able to find a way to catch the most common way the user will do this - double clicking on a line in the output window, since no command seems to be generated in this case.

    Does anyone know a way to catch this event without resorting to finding the HWND of the output window pane (presumably using EnumChildWindows and FindWindowEx) and subclassing it?

Although we didn't get any replies to that query, we (rather fortunately!) stumbled on an alternative approach within a couple of days - and in the process we also learnt a little more about how to take advantage of the VS.NET extensibility model.

What we came to realise was that we could in fact implement the behaviour we wanted by using the WindowActivated() event instead. If the window being activated is a code window, that being deactivated is the Lint Analysis pane in the output window and the text at the current line in the Output Window represents a clickable warning message, the chances are that the user has double clicked.

The code fragment below illustrates this:

void CAnalysisScheduler::WindowActivated(EnvDTE::Window* pGotFocus, EnvDTE::Window* pLostFocus)
if (NULL == m_pWindowManager)
EnvDTE::WindowPtr ptrActivatedWindow(pGotFocus);
EnvDTE::DocumentPtr ptrDocument = ptrActivatedWindow->GetDocument();
EnvDTE::WindowPtr ptrDeactivatedWindow(pLostFocus);
_bstr_t bsPathName = ptrDocument->GetFullName();
EnvDTE::vsWindowType eWindowType = ptrDeactivatedWindow->GetType();
if ( (EnvDTE::vsext_wt_OutPutWindow == eWindowType) && (bsPathName.length() > 0) )
// If the window being activated is a code editor and the deactivated window
// is the output window, check to see if the active pane within it is the
// "Lint Analysis Results" pane. If so, the user has most possibly double clicked
// on a warning and we need to show the corresponding information in the
// Warning Lookup Display
EnvDTE::WindowPtr ptrOutputWindow = ptrDeactivatedWindow;
EnvDTE::OutputWindowPtr ptrOutputWindowObject = ptrOutputWindow->GetObject();
EnvDTE::OutputWindowPanePtr ptrOutputWindowPane =
if (m_pWindowManager->IsAnalysisResultsPane(ptrOutputWindowPane) )
catch (const _com_error& e)
With corresponding implementations of the aforementioned BeforeExecute() and AfterExecute() handlers, the contents of the new display now stays synchronised with the selected warning, regardless of whether the user double clicks on the Output Window, or cycles through the warnings using commands or hotkeys.

It works like a charm.

Posted by Anna at 20:34 | Get Link


Ever wondered what your icons are up to when you're not looking?
Saturday, January 08, 2005

A little light relief for a change.

I thought I'd share a Flash animation which really made me giggle today:

Ever wondered what your icons are up to when you're not looking?.

Keep a close eye on the Diablo icon in the bottom left hand of the screen.

Posted by Anna at 21:50 | Get Link


Wide awake and ready to code - at 4am
Friday, January 07, 2005

For the last few days we've been very busy here - mainly working on our own products and making some changes to our desktop machines*. It's pretty busy, but the last few days we've not only released an update to ResOrg[^], but we've made some real progress in the development of other products. We're also doing a lot of brainstorming about new product ideas, looking at VSIP[^] get the picture. To say we are both "wired" would be a drastic understatement.

    * Two WinXP Pro boxes used for development, plus a server. As we don't tend to do most of our development work on our laptops we've configured them all to share one keyboard/mouse/monitor (a wonderfully clear Sony 18.1" TFT!). The two development machines both now share a second (15") TFT monitor arranged in portrait, courtesy of a dual input...

I finally shut VS.NET down at 11pm this evening after spending the day analysing the Visual Lint[^] source code for warnings (using itself and PC-Lint[^] - how better way to do it?) and chilled out to the box (Newnight tonight had an unusually positive report[^] on the treatment of transpeople in Iran, but that's another subject entirely...). Beth finished at a slightly more reasonable time tonight, but coming upstairs just now I did notice a Suse Linux install that wasn't there earlier this evening so she's certainly not been idle either!

About an hour and a half ago I woke up. Note just woke up, but woke up, and since then I've been lying in bed trying to shut my brain down and go back to sleep. That's plainly not working, so here I am...relaxing with a cup of Green and Blacks organic hot chocolate to (hopefully) help me to chill out and (eventually) go back to sleep. I'm having to forcibly restrain myself from diving back into the Visual Lint source code or start adding some of the next stage[^] of ResOrg features.

If this carries on I'm going t have to keep a pair of headphones and an Ozric Tentacles album next to my bed...

Posted by Anna at 04:34 | Get Link


The dust has settled on ResOrg 1.6, so it's time to start thinking about the next version
Wednesday, January 05, 2005

Now that ResOrg 1.6.1 is out, it's as good a time as any to start building a wish list for the next ResOrg release. Here are a few ideas we've got in mind, or have been suggested by users of the software:

  • Support multiple symbol files per resource file. This is a long requested feature, work on which is in underway (we had hoped to include it in 1.6, but that proved not to be practical).

  • Add group support to the Symbols Display.

  • Add a wait cursor while fixing conflicts in the Symbols Display.

  • Add mouse scroll wheel support to the Symbols Display.

  • Remove the rather odd looking border around the toolwindow in ResOrg.NET.

  • Make the Symbol Properties Dialog resizeable.

  • Integrate the add-in with the Visual Studio source code control API, so that resource symbol files and symbol configuration (.resorg) files are automatically checked out when edited.

  • Improve the integration of multi-file Symbols Displays. Specifically, make the Symbol Renumbering Wizard available within them.

  • Closer integration with Visual Studio. Although we could achieve this by repackaging the add-in as a VSPackage, the licence agreement for VSIP may preclude its use with an open source freeware product. Further investigation is required.

  • Support help context IDs.

  • Add an option to allow symbols of different types to share values. This is a long requested feature.

  • Show the useage (or lack of) of symbols. This is a decidedly non-trivial task, but would yield huge rewards.

  • Add a "Find Symbol" command. In the context of ResOrg.NET in particular, this could be incredibly useful.

  • Grouping of control IDs by useage (i.e. with dialog template ID)

This list isn't of course exhaustive - merely indicative of what may be in subsequent releases.

We welcome your comments on what features we should implement, so please feel free to post a comment giving your suggestions for what we should do next! I'll update this post periodically to include your suggestions and reflect our current development priorities.

Posted by Anna at 18:13 | Get Link


ResOrg 1.6.1 has been released
Monday, January 03, 2005

We're pleased to announce that - after a final burst of work over the Christmas holiday - the next version of ResOrg (1.6.1) is now available. You can download it either from the Downloads page or from the companion article on The CodeProject.

The main new features in this version are:

  • One much requested feature is the ability to exclude defined symbols from automated renumbering operations. A common requirement for this is to avoid issues with the default icon of an application being changed as a result of the value of IDR_MAINFRAME being changed. Such Fixed Symbols are supported by a new page in the Options Dialog.

  • The value of symbols can now be checked against a defined range for the module and symbol type. To support this feature, the preferred configuration for a resource symbol file (which defines its base values) can now optionally be saved to an XML file alongside the resource symbol file. This file is automatically written when a file is saved or the Base Values are changed.

  • Added "Next Problem" and "Previous Problem" commands to Symbols Displays to allow rapid location of symbols which may require attention. Double Clicking on the "Problem Symbols" pane (formerly "Conflicts") in the status bar automatically selects the next symbol with "a problem".

  • Added a Problem Symbol Report which shows only symbols with conflicts or values which are outside their defined range. Both this and the HTML Symbols Report now have table sorting capability (courtesy of Mike Hall at

  • Compatibility with Visual C++ .NET 2005 (note that as this is a beta product, I will continue to test against new beta versions until the product is released).
We hope you will find this a worthy upgrade. We will of course be happy to keep hearing your suggestions for further new features...

Posted by Anna at 15:35 | Get Link