Although in Visual Basic 6 all string variables are inherently Unicode, the same is not true for the components that come with it – they aren’t capable of displaying (or accepting input of, for that matter) Unicode characters. The same goes for most of the popular third party ActiveX controls that are available on the market.

Unless you’re deciding to move the form (or even the complete application) to .NET, the best solution is to use the components from the Microsoft Forms 2.0 Object Library. There are a few downsides though:

• They come with Microsoft Office and aren’t freely redistributable. But even if your clients don’t have Microsoft Office, they can legally obtain the components by installing the free Microsoft ActiveX Control Pad which contains them.
• The use of these components outside Microsoft Office isn’t officially supported. Still this shouldn’t be a problem as long as everything works. After all, even Microsoft recommends using these components in such a situation.
• The set of the components is not really complete and it might not be enough if you have a bit more complex needs. In this case there’s still UniToolbox available. I haven’t tried it but it looks a promising collection of Unicode components for Visual Basic 6. Might be worth a look.

Once the number of projects in a solution comes up to thirty or more, most of the project related operations become really slow: setting the default project, building a project starting and stopping a debug session etc. There are no noticeable slowdowns with up to twenty projects in a solution though.

Although usually no solution with real projects should reach such numbers (I stumbled upon it by just adding sample projects to the same solution), it is something to have in mind when deciding how to group projects in solutions.

Be careful when hosting your web site based on DasBlog from a Windows XP machine. While IIS 6 in Windows 2003 prevents the download of files with unknown extensions by default, the IIS 5.1 in Windows XP allows downloading such files. In the case of DasBlog all *.blogtemplate files are at risk. There are a few sites out there where these files can be downloaded. Although this probably isn’t a big security risk it might be something you want to prevent. Probably the easiest way to do that is by modifying the web.config file. You should add the following line at the end of the <httpHandlers> section:

<add verb="*" path="*.snippet" type="System.Web.HttpForbiddenHandler" />

DasBlog – the weblog engine this site is running on – allows extensibility through macros. You’ll need to use them as soon as you want any additional dynamic content on your site. (The ads you can see at the bottom of the right side bar are an example of a macro which I’ve recently updated to make the ad selection a little more advanced.) The documentation doesn’t mention their development at all therefore the following post by Vasanth Dharmaraj is probably the best source of information available on it. It actually discusses everything you need to know to get going. Make sure you read it before trying to write your first macro.

Before using EventLog.WriteEntry for adding events to event log you should consider calling EventLog.CreateEventSource to make your application a valid source of events. Keep in mind though that you need administrative privileges for it succeed, therefore it is best to call it at installation time. So, if you want to write to the application event log by calling:

EventLog.WriteEntry("MyApplicationName", "My event text");

don’t forget doing this first:

if (!EventLog.SourceExists("MyApplicationName"))
   EventLog.CreateEventSource("MyApplicationName", "Application");