VB6, like IE6 and household damp, doesn’t seem to go away easily. I had the interesting experience recently of writing a medium size piece of code in VB6, and I’ve documented how I reduced inconveniences.
Setting up a less-pain environment
The VB6 editor does not go out of its way to help you. Perhaps its greatest offence is only having 5 steps of undo. Fortunately, there’s a great VB6 mode for emacs. It’s also worth mentioning MZ-Tools, a free add-on which gives a number of useful features. Two things I found particularly helpful were code analysis (to find variables and functions which are unused) and file reload, which makes external editing easier.
Also, the VB6 IDE doesn’t support the mouse wheel. You will want the hot fix for this.
The language itself
MSDN seems to have been delibarately purged of VB6 documentation. For the initial getting up to speed in the language, there is an excellent wikibook. There’s also some useful learning material here, but there is substantial duplication between articles. Beyond this you’ll need to obtain the MSDN disks of the correct vintage (2001 I believe) and hit F1 with the function selected (the search facility leaves something to be desired).
At this point its worth mentioning VB.Net. VB.Net has had many of kinks worked out of it, so it’s a substantially different language. Migration to the .Net is definitely desirable, since support ended March 2008, but many parts of old VB6 code will need to be rewritten since the migration wizard can only do so much. Do not underestimate this task. Although the IDE is flaky on Windows Vista, the runtime is supported up to and including Windows 7. Legacy code will be around for a while yet. Note many of the curiosities listed below have been fixed in VB.Net, but most ex-VB programmers are looking elsewhere now.
Some language quirks
Testing tools are few and far between for VB6. For unit testing there is the open source SimplyVBUnit. I had some success with it, but you’ll need to examine the sample code as the documentation is rather lacking. It requires your code to be structured with a DLL server backend to a GUI frontend, which is different to a lot of legacy code. If you can get this structure you will find piecewise migration to VB.Net a lot less painful though. For GUI testing your options are even more limited, so your best option is probably a good generic GUI scripter.
Finally, beware Visual SourceSafe. It can corrupt your code history if you have too much data. Its weaknesses are expounded here. Subversion is probably the best substitute as it offers mature GUI replacements for Sourcesafe’s functionality. Integrating subversion with the VB6 IDE is tricky, there is only one piece of software that enables this. Alternatively TortoiseSVN will get the job done without the tight integration. Migration of code history is a sufficient pain that sometimes it’s easier just to check in the current build. If you want to go the automated migration route then Vss2Svn is the most mature tool available.