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 |

New development version of ResOrg.NET ( available
Monday, February 13, 2006

One of the things we';ve been wanting to do for quite some time is incorporate some of the lessons we've learnt during the development of Visual Lint into the ResOrg codebase.

I'm happy to say that we've now taken the first steps towards doing that - at least with the VS.NET version of the add-in. ResOrg.NET is also the first step towards a wider objective - bringing together the VS6 and VS.NET codebases.

On a more practical level, this release also addresses a very odd incompatibility between ResOrg.NET and some installations of Visual Assist X. More of that in a minute.

When I wrote the original incarnation of ResOrg in 2000-2001 I was strictly an MFC programmer, and the ResOrg codebase reflects this. What I'd seen of ATL3 at the time wasn't at all inspiring (it didn't even have CString support!), and I knew nothing of WTL. As a result, the ResOrg code is pretty much what you'd expect.

There's nothing wrong with that of course, but with the arrival of VS.NET 2002 and ATL7 a new way of doing things became available. Not surprisingly, the ResOrg.NET codebase is something of a hybrid. Although it does use ATL7, it's still predominantly MFC based, and when the time came to integrate a toolwindow the obvious thing to do was implement it as an MFC COleControl. With hindsight that was a mistake - ATL of course provides a far more straightforward framework for implementing ActiveX controls than MFC.

Which leads me back to Visual Assist. Some time ago, we became aware that on some ResOrg installed systems Visual Studio would just disappear while loading. It took us a while to work out what was going on, but eventually we tracked down the culprit in the debugger - Visual Assist X was silently crashing the IDE when ResOrg created its COleControl based toolwindow. If the toolwindow was disabled, they got along famously.

The solution is of course to reimplement the toolwindow in ATL/WTL. That's far from a trivial exercise so it's taken a little while, but the results are certainly worth it. I have to admit some of the mechanics of mixing WTL with MFC are rather weird, but it does work at the end of the day!

At the same time we've taken the opportunity to bring some of the Visual Lint code across to ResOrg.NET - notably in the use of COM smart pointers rather than raw interfaces, and improvements to the way installation and commands are managed.

The full list of changes is as follows:

  • CConnect::OnConnection() now recreates the add-in's commands if necessary when it is loaded under normal startup conditions. This should remove the need for re-installation solely to recreate the add-ins's commands.

  • Added a post build step to copy the Satellite DLL to the Bin\1033 folder

  • Moved CVc6AutomationHelper and CVc7AutomationHelper to the ResOrgAddIn and
    ResOrgNETAddIn projects respectively.

  • Integrated ATL CMainToolWindowCtrl, which replaces the original MFC OLE Control.

  • Reorganised the way commands are implemented.

  • CResOrgAddInApp::InitInstance() now sets the resource instance of _AtlModule. This is required to be able to access the satellite DLLs resources correctly.

  • DllRegisterServer() now sets all keys necessary to load the add-in, making installation far simpler and more robust.

  • Modified #imports for DTE and MSO to import smart pointer interfaces as well as raw ones. Also included lint directives so PC-Lint can identify the .tlh and .tli files for interfaces imported by LIBID.

  • All dialogs now use Win2k/XP system fonts
Incidentally, we've released this build as a development version as we hope to be developing the product further in the coming months. In particular, we have more work to do on VS2005 compatibility, notably with regard to its command architecture.

Posted by Anna at 06:58 | Get Link