Tuesday, November 22, 2005

List of Invalid Keyboard Characters for a Windows XP filename

What keyboard characters are not valid for a Windows XP filename?

This has come up several times over the years during my programming tasks when I have tried to automatically generate a filename based on some collection of data. It seems a good time to document this relatively simple question for my future reference as well as yours.

The keyboard characters that cannot be used in a Windows XP filename are:

* Asterisk

Pipe (vertical bar)

\ Back slash

/ Forward slash

: Colon

" Quote

< Less Than

> Greater Than

? Question mark


Hope that helps!
Joe Kunk

Thursday, November 17, 2005

Preparation steps for converting Visual Basic 6 code into Visual Basic.Net 2005

If you have Visual Basic 6 code that you want to convert to Visual Basic.Net, I strongly recommend that you use the Wizard included in Visual Studio 2005, it is much enhanced compared to what is available in Visual Studio 2003.

Note that it is a good investment of your time to go into the Visual Basic 6 source code, make sure that you have the "Option Explicit" statement as the first line of code in each form and module, and then make the needed changes to get a good compile with the correct functionality. This pre-conversion step can significantly reduce the manual changes needed to your code once it is Visual Basic.Net.

Since Visual Basic.Net is a strongly-typed language, any variables in the Visual Basic 6 that are not explicitly declared will be defined as type "Object" in the Visual Basic.Net code and will require type conversion statements to be written manually at locations where they are referenced. It is best to avoid this post-conversion effort by ensuring that the Visual Basic 6 source code has only explicitly defined variables.

Late-bound object references in Visual Basic 6 represent a similar problem. Late-bound references were typically used in Visual Basic 6 to interface to Microsoft Office products or other COM based interfaces in a non-version specific manner. Programs of this type will typically not covert well. For Microsoft Office interface applications, you may want to consider rewriting the software directly in Visual Basic.Net using Visual Studio Tools for Office (VSTO). Note that VSTO requires MS Office 2003. For non-office applications, you will want to consider rewriting the application using early-bound methods by directly referencing the DLL at compile time. If needed, Visual Basic.Net still supports late-bound COM object, but there will be a significant performance penalty.

I hope you find this helpful.

Joe Kunk