I was working with XML serialization of objects recently and was using the good ol’ DataContractSerializer again.

One thing that I bumped into almost immediately is that the XML that it spits out isn’t exactly the neatest, tidiest of XML possible, to say the least.

So I set out on a little odyssey to see exactly how nice and clean I could make it.

(EDIT: I’ve added more information about how the Name property of the Field object is being serialized twice, which is another big reason for customizing the serialization here, and for specialized dictionary serialization in general).

First, the objects to serialize. I’ve constructed a very rudimentary object hierarchy that still illustrates the problem well.

In this case, I have a List of Record objects, called a Records list. Each Record object is a dictionary of Field objects. And each Field object contains two properties, Name and Value. The code for these (and a little extra code to make populating them easy) is as follows.

Public Class Records
    Inherits List(Of Record)


    Public Sub New()
        '---- default constructor
    End Sub

End Class


Public Class Record
    Inherits Dictionary(Of String, Field)


    Public Sub New()
        '---- default constructor
    End Sub


    Public Sub New(ByVal ParamArray Fields() As Field)
        For Each f In Fields
            Me.Add(f.Name, f)
        Next
    End Sub
End Class


Public Class Field

    Public Sub New()
        '---- default constructor
    End Sub


    Public Sub New(ByVal Name As String, ByVal Value As String)
        Me.Name = Name
        Me.Value = Value
    End Sub


    Public Property Name() As String
        Get
            Return _Name
        End Get
        Set(ByVal value As String)
            _Name = value
        End Set
    End Property
    Private _Name As String



    Public Property Value() As String
        Get
            Return _Value
        End Get
        Set(ByVal value As String)
            _Value = value
        End Set
    End Property
    Private _Value As String

End Class

Yes, I realize there are DataTables, KeyValuePair objects, etc that could do this, but that’s not the point, so just bear with me .

To populate a Records object, you might have code that looks like this:

Dim Recs = New Records
Recs.Add(New Record(New Field("Name", "Darin"), New Field("City", "Arlington")))
Recs.Add(New Record(New Field("Name", "Gillian"), New Field("City", "Ft Worth")))
Recs.Add(New Record(New Field("Name", "Laura"), New Field("City", "Dallas")))

Ok, so far so good.

Now, lets serialize that with a simple serialization function using the DataContractSerializer:

    ''' <summary>
    ''' Serializes the data contract to a string (XML)
    ''' </summary>
    Public Function Serialize(Of T As Class)(ByVal SerializeWhat As T) As String
        Dim stream = New System.IO.StringWriter
        Dim writer = System.Xml.XmlWriter.Create(stream)

        Dim serializer = New System.Runtime.Serialization.DataContractSerializer(GetType(T))
        serializer.WriteObject(writer, SerializeWhat)
        writer.Flush()

        Return stream.ToString
    End Function

In the test application, I put together, I dump the resulting XML to a text box. Yikes!

So, what’re the problems here?

1. You’ve got that “http://www.w3.org/2001/XMLSchema-instance” namespace attribute amongst other
2. lots of random letters
3. no indenting
4. You can’t really tell it from this shot, but the Record dictionary is serializing the name property twice, because I’m using it as the Key for the dictionary, but it’s also a property of the objects in the dictionary.

All this noise might be fine for computer to computer communication, but it’s pretty tough on human eyes .

Ok, first thing to do is indent:

    ''' <summary>
    ''' Serializes the data contract to a string (XML)
    ''' </summary>
    Public Function Serialize(Of T As Class)(ByVal SerializeWhat As T) As String
        Dim stream = New System.IO.StringWriter
        Dim xmlsettings = New Xml.XmlWriterSettings
        xmlsettings.Indent = True
        Dim writer = System.Xml.XmlWriter.Create(stream, xmlsettings)

        Dim serializer = New System.Runtime.Serialization.DataContractSerializer(GetType(T))
        serializer.WriteObject(writer, SerializeWhat)
        writer.Flush()

        Return stream.ToString
    End Function

Notice that I added the use of the XMLWriterSettings object. This allows me to set the Indent property, and things are much more readable.

But that’s still a far cry from nice, simple, tidy XML. Notice all the “ArrayofArrayOf blah blah” names, and the randomized letter sequences? Plus, it’s much more obvious how the NAME jproperty is being serialized twice now. Yuck! Surely, we can do better than this!

Cleaning Up the Single Entity Field Object

The DataContractSerializer certainly works easily enough to serialize the Field object, but unfortunately, it decorates the serialized elements with a load of really nasty looking and completely unnecessary cruft.

My first thought was to simply decorate the class with <DataContract> attributes:

<DataContract(Name:="Field", Namespace:="")> _
Public Class Field

    Public Sub New()
        '---- default constructor
    End Sub


    Public Sub New(ByVal Name As String, ByVal Value As String)
        Me.Name = Name
        Me.Value = Value
    End Sub

    <DataMember()> _
    Public Property Name() As String
        Get
            Return _Name
        End Get
        Set(ByVal value As String)
            _Name = value
        End Set
    End Property
    Private _Name As String



    <DataMember()> _
    Public Property Value() As String
        Get
            Return _Value
        End Get
        Set(ByVal value As String)
            _Value = value
        End Set
    End Property
    Private _Value As String

End Class

But this yields:

So we have several problems:

• Each field is rendered into a Value element of the Record’s field collection
• The Key of the Record collection duplicates the Name of the individual Field objects
• and we still have a noxious xmlns=”” attribute being rendered.

Unfortunately, this is where the DataContractSerializer’s simplicity is it’s downfall. There’s just no way to customize this any further, using ONLY the DataContractSerializer.

However, we can implement IXMLSerializable on our Field object to customize its serialization. All I need to do is remove the DataContract attribute, and add a simple implementation of IXMLSerializable to the class:

Public Class Field
    Implements System.Xml.Serialization.IXmlSerializable


    Public Sub New()
        '---- default constructor
    End Sub


    Public Sub New(ByVal Name As String, ByVal Value As String)
        Me.Name = Name
        Me.Value = Value
    End Sub

    Public Property Name() As String
        Get
            Return _Name
        End Get
        Set(ByVal value As String)
            _Name = value
        End Set
    End Property
    Private _Name As String


    Public Property Value() As String
        Get
            Return _Value
        End Get
        Set(ByVal value As String)
            _Value = value
        End Set
    End Property
    Private _Value As String


    Public Function GetSchema() As System.Xml.Schema.XmlSchema Implements System.Xml.Serialization.IXmlSerializable.GetSchema
        Return Nothing
    End Function


    Public Sub ReadXml(ByVal reader As System.Xml.XmlReader) Implements System.Xml.Serialization.IXmlSerializable.ReadXml

    End Sub


    Public Sub WriteXml(ByVal writer As System.Xml.XmlWriter) Implements System.Xml.Serialization.IXmlSerializable.WriteXml
        writer.WriteElementString("Name", Me.Name)
        writer.WriteElementString("Value", Me.Value)
    End Sub
End Class

And that yields a serialization of:

Definitely better, but still not great.

Cleaning up a Generic Dictionary’s Serialization

The problem now is with the Record dictionary.

Public Class Record
    Inherits Dictionary(Of String, Field)
    Implements System.Xml.Serialization.IXmlSerializable


    Public Sub New()
        '---- default constructor
    End Sub


    Public Sub New(ByVal ParamArray Fields() As Field)
        For Each f In Fields
            Me.Add(f.Name, f)
        Next
    End Sub

    Public Function GetSchema() As System.Xml.Schema.XmlSchema Implements System.Xml.Serialization.IXmlSerializable.GetSchema
        Return Nothing
    End Function

    Public Sub ReadXml(ByVal reader As System.Xml.XmlReader) Implements System.Xml.Serialization.IXmlSerializable.ReadXml

    End Sub

    Public Sub WriteXml(ByVal writer As System.Xml.XmlWriter) Implements System.Xml.Serialization.IXmlSerializable.WriteXml
        For Each f In Me.Values
            DirectCast(f, System.Xml.Serialization.IXmlSerializable).WriteXml(writer)
        Next
    End Sub
End Class

Adding an IXMLSerializable implementation to it as well yields the following XML:

Definitely much better! Especially notice that we’ve gotten rid of the duplicated “Name” key. It was duplicated before because we used the Name element of the Field object as the Key for the Record dictionary. This be play an important part in deserializing the Record’s dictionary of Field objects later.

Cleaning up the List of Records

Finally, the only thing really left to do is clean up how the generic list of Record objects is serialized.

But once again, the only way to alter the serialization is to implement IXMLSerializable on the class.

<Xml.Serialization.XmlRoot(Namespace:="")> _
Public Class Records
    Inherits List(Of Record)
    Implements System.Xml.Serialization.IXmlSerializable


    Public Sub New()
        '---- default constructor
    End Sub

    Public Function GetSchema() As System.Xml.Schema.XmlSchema Implements System.Xml.Serialization.IXmlSerializable.GetSchema
        Return Nothing
    End Function

    Public Sub ReadXml(ByVal reader As System.Xml.XmlReader) Implements System.Xml.Serialization.IXmlSerializable.ReadXml

    End Sub

    Public Sub WriteXml(ByVal writer As System.Xml.XmlWriter) Implements System.Xml.Serialization.IXmlSerializable.WriteXml
        For Each r In Me
            DirectCast(r, System.Xml.Serialization.IXmlSerializable).WriteXml(writer)
        Next
    End Sub
End Class

Notice that I’ve implemented IXMLSerializable, but I also added the XmlRoot attribute with a blank Namespace parameter. This completely clears the Namespace declaration from the resulting output, which now looks like this:

And that is just about as clean as your going to get!

But That’s Not all there is To It

Unfortunately, it’s not quite this simple. The thing is, you very well may want to serialize each object independently, not just serialize the Records collection. Doing that as we have things defined right now won’t work. The Start and End elements won’t be generated in the XML properly.

Instead, we need to add XmlRoot attributes to all three classes, and adjust where the WriteStartElement and WriteEndElement calls are made. So we end up with this:

<Xml.Serialization.XmlRoot(Namespace:="")> _
Public Class Records
    Inherits List(Of Record)
    Implements System.Xml.Serialization.IXmlSerializable


    Public Sub New()
        '---- default constructor
    End Sub

    Public Function GetSchema() As System.Xml.Schema.XmlSchema Implements System.Xml.Serialization.IXmlSerializable.GetSchema
        Return Nothing
    End Function

    Public Sub ReadXml(ByVal reader As System.Xml.XmlReader) Implements System.Xml.Serialization.IXmlSerializable.ReadXml

    End Sub

    Public Sub WriteXml(ByVal writer As System.Xml.XmlWriter) Implements System.Xml.Serialization.IXmlSerializable.WriteXml
        For Each r In Me
            writer.WriteStartElement("Record")
            DirectCast(r, System.Xml.Serialization.IXmlSerializable).WriteXml(writer)
            writer.WriteEndElement()
        Next
    End Sub
End Class


<Xml.Serialization.XmlRoot(ElementName:="Record", Namespace:="")> _
Public Class Record
    Inherits Dictionary(Of String, Field)
    Implements System.Xml.Serialization.IXmlSerializable


    Public Sub New()
        '---- default constructor
    End Sub


    Public Sub New(ByVal ParamArray Fields() As Field)
        For Each f In Fields
            Me.Add(f.Name, f)
        Next
    End Sub

    Public Function GetSchema() As System.Xml.Schema.XmlSchema Implements System.Xml.Serialization.IXmlSerializable.GetSchema
        Return Nothing
    End Function

    Public Sub ReadXml(ByVal reader As System.Xml.XmlReader) Implements System.Xml.Serialization.IXmlSerializable.ReadXml

    End Sub

    Public Sub WriteXml(ByVal writer As System.Xml.XmlWriter) Implements System.Xml.Serialization.IXmlSerializable.WriteXml
        For Each f In Me.Values
            writer.WriteStartElement("Field")
            DirectCast(f, System.Xml.Serialization.IXmlSerializable).WriteXml(writer)
            writer.WriteEndElement()
        Next
    End Sub
End Class


<Xml.Serialization.XmlRoot(ElementName:="Field", Namespace:="")> _
Public Class Field
    Implements System.Xml.Serialization.IXmlSerializable


    Public Sub New()
        '---- default constructor
    End Sub


    Public Sub New(ByVal Name As String, ByVal Value As String)
        Me.Name = Name
        Me.Value = Value
    End Sub

    Public Property Name() As String
        Get
            Return _Name
        End Get
        Set(ByVal value As String)
            _Name = value
        End Set
    End Property
    Private _Name As String


    Public Property Value() As String
        Get
            Return _Value
        End Get
        Set(ByVal value As String)
            _Value = value
        End Set
    End Property
    Private _Value As String


    Public Function GetSchema() As System.Xml.Schema.XmlSchema Implements System.Xml.Serialization.IXmlSerializable.GetSchema
        Return Nothing
    End Function


    Public Sub ReadXml(ByVal reader As System.Xml.XmlReader) Implements System.Xml.Serialization.IXmlSerializable.ReadXml

    End Sub


    Public Sub WriteXml(ByVal writer As System.Xml.XmlWriter) Implements System.Xml.Serialization.IXmlSerializable.WriteXml
        writer.WriteElementString("Name", Me.Name)
        writer.WriteElementString("Value", Me.Value)
    End Sub
End Class
 
 

And Finally, Deserialization

Of course, all this would be for nought if we couldn’t actually deserialize the xml we’ve just spent all this effort to clean up.

Turns out that deserialization is pretty straightforward. I just needed to add code to the ReadXml member of the implemented IXMLSerializable interface. The full code for my testing form is below. Be sure to add a reference to System.Runtime.Serialization, though, or you’ll have type not defined errors.

Public Class frmSample

    Private Sub btnTest_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles btnTest.Click

        '---- populate the objects
        Dim Recs = New Records
        Recs.Add(New Record(New Field("Name", "Darin"), New Field("City", "Arlington")))
        Recs.Add(New Record(New Field("Name", "Gillian"), New Field("City", "Ft Worth")))
        Recs.Add(New Record(New Field("Name", "Laura"), New Field("City", "Dallas")))

        Dim t As String
        t = Serialize(Of Field)(Recs(0).Values(0))
        Dim fld = Deserialize(Of Field)(t)
        Debug.Print(fld.Name)
        Debug.Print(fld.Value)
        Debug.Print("--------------")

        t = Serialize(Of Record)(Recs(0))
        Dim rec = Deserialize(Of Record)(t)
        Debug.Print(rec.Values.Count)
        Debug.Print("--------------")

        t = Serialize(Of Records)(Recs)
        tbxOutput.Text = t

        Dim recs2 = Deserialize(Of Records)(t)
        Debug.Print(recs2.Count)
    End Sub
End Class


<Xml.Serialization.XmlRoot(Namespace:="")> _
Public Class Records
    Inherits List(Of Record)
    Implements System.Xml.Serialization.IXmlSerializable


    Public Sub New()
        '---- default constructor
    End Sub

    Public Function GetSchema() As System.Xml.Schema.XmlSchema Implements System.Xml.Serialization.IXmlSerializable.GetSchema
        Return Nothing
    End Function

    Public Sub ReadXml(ByVal reader As System.Xml.XmlReader) Implements System.Xml.Serialization.IXmlSerializable.ReadXml
        reader.MoveToContent()
        reader.ReadStartElement("Records")
        reader.MoveToContent()
        Do While reader.NodeType <> Xml.XmlNodeType.EndElement
            Dim Rec = New Record
            DirectCast(Rec, System.Xml.Serialization.IXmlSerializable).ReadXml(reader)
            Me.Add(Rec)
            reader.MoveToContent()
        Loop
        reader.ReadEndElement()
    End Sub

    Public Sub WriteXml(ByVal writer As System.Xml.XmlWriter) Implements System.Xml.Serialization.IXmlSerializable.WriteXml
        For Each r In Me
            writer.WriteStartElement("Record")
            DirectCast(r, System.Xml.Serialization.IXmlSerializable).WriteXml(writer)
            writer.WriteEndElement()
        Next
    End Sub
End Class


<Xml.Serialization.XmlRoot(ElementName:="Record", Namespace:="")> _
Public Class Record
    Inherits Dictionary(Of String, Field)
    Implements System.Xml.Serialization.IXmlSerializable


    Public Sub New()
        '---- default constructor
    End Sub


    Public Sub New(ByVal ParamArray Fields() As Field)
        For Each f In Fields
            Me.Add(f.Name, f)
        Next
    End Sub

    Public Function GetSchema() As System.Xml.Schema.XmlSchema Implements System.Xml.Serialization.IXmlSerializable.GetSchema
        Return Nothing
    End Function

    Public Sub ReadXml(ByVal reader As System.Xml.XmlReader) Implements System.Xml.Serialization.IXmlSerializable.ReadXml
        reader.MoveToContent()
        reader.ReadStartElement("Record")
        reader.MoveToContent()
        Do While reader.NodeType <> Xml.XmlNodeType.EndElement
            Dim fld = New Field
            DirectCast(fld, System.Xml.Serialization.IXmlSerializable).ReadXml(reader)
            Me.Add(fld.Name, fld)
            reader.MoveToContent()
        Loop
        reader.ReadEndElement()
    End Sub

    Public Sub WriteXml(ByVal writer As System.Xml.XmlWriter) Implements System.Xml.Serialization.IXmlSerializable.WriteXml
        For Each f In Me.Values
            writer.WriteStartElement("Field")
            DirectCast(f, System.Xml.Serialization.IXmlSerializable).WriteXml(writer)
            writer.WriteEndElement()
        Next
    End Sub
End Class


<Xml.Serialization.XmlRoot(ElementName:="Field", Namespace:="")> _
Public Class Field
    Implements System.Xml.Serialization.IXmlSerializable


    Public Sub New()
        '---- default constructor
    End Sub


    Public Sub New(ByVal Name As String, ByVal Value As String)
        Me.Name = Name
        Me.Value = Value
    End Sub

    Public Property Name() As String
        Get
            Return _Name
        End Get
        Set(ByVal value As String)
            _Name = value
        End Set
    End Property
    Private _Name As String


    Public Property Value() As String
        Get
            Return _Value
        End Get
        Set(ByVal value As String)
            _Value = value
        End Set
    End Property
    Private _Value As String


    Public Function GetSchema() As System.Xml.Schema.XmlSchema Implements System.Xml.Serialization.IXmlSerializable.GetSchema
        Return Nothing
    End Function


    Public Sub ReadXml(ByVal reader As System.Xml.XmlReader) Implements System.Xml.Serialization.IXmlSerializable.ReadXml
        reader.MoveToContent()
        reader.ReadStartElement("Field")
        reader.MoveToContent()
        If reader.Name = "Name" Then Me.Name = reader.ReadElementContentAsString
        reader.MoveToContent()
        If reader.Name = "Value" Then Me.Value = reader.ReadElementContentAsString
        reader.MoveToContent()
        reader.ReadEndElement()
    End Sub


    Public Sub WriteXml(ByVal writer As System.Xml.XmlWriter) Implements System.Xml.Serialization.IXmlSerializable.WriteXml
        writer.WriteElementString("Name", Me.Name)
        writer.WriteElementString("Value", Me.Value)
    End Sub
End Class



Public Module Serialize
    ''' <summary>
    ''' Serializes the data contract to a string (XML)
    ''' </summary>
    Public Function Serialize(Of T As Class)(ByVal SerializeWhat As T) As String
        Dim stream = New System.IO.StringWriter
        Dim xmlsettings = New Xml.XmlWriterSettings
        xmlsettings.Indent = True
        Dim writer = System.Xml.XmlWriter.Create(stream, xmlsettings)

        Dim serializer = New System.Runtime.Serialization.DataContractSerializer(GetType(T))
        serializer.WriteObject(writer, SerializeWhat)
        writer.Flush()

        Return stream.ToString
    End Function


    ''' <summary>
    ''' Deserializes the data contract from xml.
    ''' </summary>
    Public Function Deserialize(Of T As Class)(ByVal xml As String) As T
        Using stream As New MemoryStream(UnicodeEncoding.Unicode.GetBytes(xml))
            Return DeserializeFromStream(Of T)(stream)
        End Using
    End Function


    ''' <summary>
    ''' Deserializes the data contract from a stream.
    ''' </summary>
    Public Function DeserializeFromStream(Of T As Class)(ByVal stream As Stream) As T
        Dim serializer As New DataContractSerializer(GetType(T))
        Return DirectCast(serializer.ReadObject(stream), T)
    End Function
End Module

Of particular note above is the ReadXML function of the Field object.

It checks the name of the node first and then places the value of the node into the appropriate property of that object. If I didn’t do that, the deserialization process would require the fields in the XML to be in a specific order. This is a minor drawback to the DataContractSerializer that this approach alleviates.

What’s Next?

The one unfortunate aspect of this is that it requires you to implement IXMLSerializable on each object that you want the XML cleaned up for.

Generally speaking, The DataContractSerializer will be perfectly fine for those cases where humans aren’t likely to ever have to see the XML you’re generating. And you get a performance boost for sacrificing that flexibility and “cleanliness”.

But for things like data file imports, custom configuration files, and the like, it may be desirable to  implement custom serialization like this so that your xml files can be almost as easy to read as those old school INI files!

I’ve been playing recently with the amBX ambient effects library and devices.

Essentially, it’s an effects platform that allows you to easily create light, wind and rumble effects to coordinate with what’s going on on-screen, in a game, in media players, or what-have-you. The lighting effects are nothing short of fantastic. The rumble and fan effects…. meh. They’re interesting, but I’m not sure where that’ll go.

Regardless, the API for amBX is all C style objects, which means essentially an array of function pointers to the methods of the object; not really an API that VB.net likes to consume. Be sure to grab the amBX developer kit here. You’ll also need to core amBX software available from the main website. Finally, play around with the “Virtual amBX Test Tool”. It’ll allow you to experiment with all the amBX features and functions without having to buy anything at all. Of course, eventually you’ll want to get at least the starter kit, with the lights. But it’s not necessary to begin experimenting.

Hats off to Philips for making this possible!

Here’s an example of the structure definition from the amBX.h header file that comes with the API (I’ve clipped out comments and other bits):

struct IamBX {
    amBX_RESULT (*release) (struct IamBX * pThis);
    amBX_RESULT (*createLight) (struct IamBX * pThis,
                                amBX_u32 loc,
                                amBX_u32 height,
                                struct IamBX_Light** ppLight);
....

As you can see, each element in the structure is made up of a pointer to a function. The various functions all take, as their first argument, a pointer back to this structure. Under the covers, this is how virtually all object oriented languages function, it’s just the the compiler usually hides all this nasty plumbing so you don’t have to deal with it regularly.

But this presents a problem. VB.net is “managed” code, and as such, it likes things to be wrapped up in nice “managed” bits. There are plenty of good reasons for this, but these function pointers are decidedly not nice and tidy managed bits! So, what to do?

One solution is the approach Robert Grazz took here. It’s a solid solution, no doubt, and I learned a lot from looking at his approach, but, this being VBFengShui, I wanted that same functionality in native VB.net with no additional dll files hanging around!

Delegates to the Rescue!

A delegate in .net is essentially a managed function pointer. In VB.net, they’re most commonly used to handle events, but you wouldn’t really know it, because VB’s compiler does a good job of hiding all that plumbing from you. However, unlike VB6 and earlier, in VB.net, all the plumbing can, if you’re willing, be “brought into the daylight” and used however you want.

There are many, many discussions about delegates for VB.net out on the web. A really good Introduction to the concepts by Malli_S is on codeproject, so I won’t rehash the basics here.

The problem is, delegates in VB.net tend to be generated by using the AddressOf operator, and I already had the function addresses (they’re in that C structure). I just needed to get a delegate that would allow me to call it.

Some Googling turned up several good posts that provided pointers, including this one on StackOverflow. But it wasn’t exactly all the steps necessary.

Getting the C Structure

The first step toward getting something working with amBX is to retrieve the main amBX object. You do this through a standard Windows DLL call.

<DllImport("ambxrt.dll", ExactSpelling:=True, CharSet:=CharSet.Auto)> _
        Public Shared Function amBXCreateInterface(ByRef IamBXPtr As IntPtr, ByVal Major As UInt32, ByVal Minor As UInt32, ByVal AppName As String, ByVal AppVer As String, ByVal Memptr As Integer, ByVal UsingThreads As Boolean) As Integer
        End Function

Assuming you have the ambxrt.dll file somewhere on your path or in the current dir, the call will succeed, but what exactly does that mean?

Here’s an example of a call to it in C:

    if (amBXCreateInterface(
            &pEngineHandle, 
            majorVersion, minorVersion, 
            (amBX_char*)cAppName.ToPointer(), (amBX_char*)cAppName.ToPointer(),
            nullptr, false)
        != amBX_OK)

Essentially, you pass in the Major and minor version numbers of the Version of amBX you need, and two strings indicating the name of your app and the version of your app. No problems with any of that. But that &EngineHandle is the trick.

It means that this call will return a 4 byte pointer to a block of memory that contains the amBX object structure, which is, itself, an array of 4 byte function pointers to the various methods of the amBX object. Therefore, in VB.net, that argument is declared ByRef IamBXPtr as IntPtr.

Now, we need a place to store that “structure of pointers.” Going through the ambx.h file, I ended up with a structure that looks like this:

        <StructLayout(LayoutKind.Sequential)> _
        Private Structure IamBX
            Public ReleasePtr As IntPtr
            Public CreateLightPtr As IntPtr
            Public CreateFanPtr As IntPtr
            Public CreateRumblePtr As IntPtr
            Public CreateMoviePtr As IntPtr
            Public CreateEventPtr As IntPtr
            Public SetAllEnabledPtr As IntPtr
            Public UpdatePtr As IntPtr
            Public GetVersionInfoPtr As IntPtr
            Public RunThreadPtr As IntPtr
            Public StopThreadPtr As IntPtr
        End Structure

That StructLayout attribute is particularly important. It tells the compiler that the structure should be layed out in memory JUST AS it’s declared in source code. Otherwise, the compiler could possibly rearrange elements on us. With Managed Code, that’d be no problem, but when working with unmanaged C functions, that would not be a good thing!

And finally, we need a way to retrieve that function pointer array and move it into the structure above, so that it’s easier to work with from VB.net. That’s where the System.Runtime.InteropServices.Marshal.PtrToStructure function comes in. This routine will copy a block of unmanaged memory directly into a managed structure.

Private _IamBX As IamBX
Private _IamBXPtr As IntPtr
...

amBXCreateInterface(_IamBXPtr, 1, 0, “MyAppName”, “1.0”, 0, False)

_IamBX = Marshal.PtrToStructure(_IamBXPtr, GetType(IamBX))

And presto, you should now have the _IamBX structure filled in with the function pointers of all the methods of this C “Object”.

Calling the C Function Pointer

At this point, we’ve got everything necessary to call the function pointer. Take the CreateLight function. The C prototype for this function is shown at the top of this page. As arguments, it takes a pointer back to the amBX structure, 2 32bit integers describing the location and height of the light source, and it returns are pointer to another structure, in this case, an amBX_Light structure, which contains another set of function pointers, just like the amBX structure described above.

First, we need to declare a delegate that matches the calling signature of the CreateLight C function we’ll be calling:

<UnmanagedFunctionPointer(CallingConvention.Cdecl)> _
Private Delegate Function CreateLightDelegate(
         ByVal IamBXPtr As IntPtr, _
         ByVal Location As Locations, _
         ByVal Height As Heights, _
         ByRef IamBXLightPtr As IntPtr) As amBX_RESULT

The key points here are:

1. Make sure you have the CallingConvention attribute set right. Most C libraries will be CDECL, but some libraries are STDCALL.
2. Make sure your parameter types match, especially in their sizes. Not doing this will lead to corrupted called or system crashes.

Now, create a variable for the delegate and use the Marshal.GetDelegateFromFunctionPointer function to create a new instance of the delegate, based on the applicable function pointer. Since the function pointer for the CreateLight function is stored in the CreateLightPtr field of the _IamBX structure, we pass that in as the pointer argument.

IMPORTANT NOTE: There are 2 overloads for the Marshal.GetDelegateFromFunctionPointer  function. Be sure to use the one what requires a second argument of the TYPE of the delegate to create. Using the other one will fail at runtime because it won’t be able to dynamically determine the type of delegate to create.

Next, call the function via the delegate, just as if it was a function itself.

Finally, use Marshal.PtrToStructure again to copy the array of function pointers returned into another structure, this one formatted to contain the function pointers of the Light object that just got created.

Dim d As CreateLightDelegate = Marshal.GetDelegateForFunctionPointer(_IamBX.CreateLightPtr, GetType(CreateLightDelegate))
Dim r = d(_IamBXPtr, Location, Height, _IamBXLightPtr)
_IamBXLight = Marshal.PtrToStructure(_IamBXLightPtr, GetType(IamBX_Light))

The amBX library is much, much larger than just this little bit I’ve shown here. Once I get the entire thing coded up, I’ll be presenting it here as well.

But in the meantime, if you have a need to interface with C style function pointer objects, don’t let anyone tell you it can’t be done in VB.net

Final Note

As you may or may not have guessed, amBX is a 32bit library and its interfaces, functions and arguments all live in 32bit land. If you’re working with VS2008, BE SURE to set your project to the x86 platform, and NOT “Any CPU” or “x64”! The default, for whatever reason is “Any CPU”, which means things will work properly when run under 32bit windows, but things won’t work well at all if run under a 64bit OS.

At one point a while back (while I was still working for my previous company), we had “support for x64” handled down as a request for an interim version.

I thought, “No sweat”. Grab a few alternative prerequisite MSIs, determine the bitness of the processor you’re on in the install (InstallShield has the functionality built in), and just fire off the appropriate preqs. Our actual application is 32bit, and we had no intention or need to compile as 64bit.

Well. A few clicks later and the install was built and deployed to a test machine.

Crash.

Initial sample database didn’t get deployed properly.

Ok, why not. Well. Long story short, the application couldn’t find a registry key setting. But I hadn’t changed anything about the registry.

Lots of digging through verbose install logs later, and I discovered that the installer was, on a 64bit OS creating registry keys under the key  HKEY_CURRENT_USER\Software\Wow6432Node whereas when my application when to get the registry key, it was looking in the normal HKEY_CURRENT_USER\Software\ key.

Huh?!

First, what the hell was this Wow6332Node? Obviously it’s some kind of “compatibility” bit for running 32bit apps under a 64bit OS. And that’s exactly what it is.

Ok, my Installer is InstallShield, and it’s a 32bit app (even if it can install 64bit packages), so that explains why it was writing the key to that Wow6432Node, but why wasn’t my application reading it from there?

A little digging later, and I found this option buried in the “Advanced Compiler Settings” panel of the “Compile Options” tab of the Project’s properties.

See that AnyCPU setting? When set to AnyCPU, the JIT compiler will dynamically compile your .net dll as either a 32bit or 64bit dll, depending on the process that loaded it.

Obviously, on a 32bit OS, all the processes will be 32bit, so everything’s 32bit.

BUT, on a 64bit OS, things get nastier.

If the DLL runs under a native code 32bit process, it’ll get compiled as 32bit x86 code and run under the Wow32 (Windows On Windows) layer. This explains why the DLL that acts as an AddIn to Word worked just fine. Word is a native 32bit process, so the DLL was ending up executing as 32bit too.

However, the little utility app that creates our initial database was a .net application, and it was set to AnyCPU.

That meant that when IT loaded our DLL, the DLL ended up JITed to 64bit code (because the utility app was set to AnyCPU, so it was JITed to 64bit code because it was a base process and was running under a 64bit OS.

Case closed.

Short version of the story. Since tracing all this down, I’ve learned that for VS2008, the .net team decided to change the default of that option from x86 to AnyCPU, and then, in general, that has been regarded as a bad thing to have done.

The default will be changed BACK to x86 in 2010 apparently, but until then, unless you REALLY need to compile code for AnyCPU, be sure to switch this option back to x86!

Recently, I ran into a need to make use of the Mono.Cecil.dll library from a .net application I was working on. Cecil is a fantastic little project under the Mono project that allows you to interrogate an existing .net assembly (EXE or DLL file) and retrieve all kinds of information about the assembly, from the resources embedded within it to the classes and methods defined, and much more. You can even alter the contents of the assembly and write the new version back out to disk!

The thing is, Cecil comes prebuilt as a C# assembly (a DLL file), and I really did not want to have a second file required for this particular application (it’s just a little command line utility).

My first take was to use Oren Eini’s excellent concept of an assembly locator. My idea here was to embed an assembly as a binary resource, then, when requested, read that resource into a stream, load the assembly from the stream, and resolve references to it via the assembly locator.

I’m still working on that concept, because I think it’s a clever and convenient solution to the problem, but, in researching that, I happened to remember the even easier (as in, no code required at all!) solution of using ILMerge.

ILMerge

If you haven’t already discovered it, ILMerge is a Microsoft research project in the form of a single command line EXE utility, that can “merge” any number of .net assemblies with a “target” assembly, and produce either a .net DLL or EXE output file.

There’s a really good article on CodeProject describing the general use of the program. There’s even a GUI (Gilma) for it.

Automating ILMerge

What the article doesn’t go into is automating the ILMerge process. After all, you won’t want to manually run that command line utility every time you build your application!

The good thing is, it’s trivially easy to automate as long as you take care of one critical step.

• First, download and install ILMerge from the link above.
• Once it’s installed be sure to copy the ILMerge.exe utility to somewhere on your path (or add the folder it’s in to your path).
• Then, grab the Mono.Cecil.dll file (or whatever DLL it is you want to merge into your main project EXE). Put it in the root folder of your project.
• Go ahead and set a reference to that file, so you still get all the .net intellisense goodness, but be sure to set the Copy Local property for the reference to FALSE (after all, you don’t want to copy this DLL to the output folder along with the application if you don’t actually need it, right?)

  

• With that done, you MAY want to mark the DLL you’re embedding as “included in project” from the Solution Explorer.

If you do this, however, make sure you also set the Copy to Output Folder to “Do not copy” (that’s the default though so it should already be set).

The Tricky Part

One limitation of ILMerge is it that it can’t alter the target assembly “in place”. This means that, for instance, if you want the final resulting executable file name to be called GenerateLineMap (my utility), you can’t have VS compile the assembly to that name. You’ll need to use some other name for the initially compiled assembly.

On the Application tab of the project properties you can change that name, like so:

I just added “-Interim” to the Assembly Name.

Now, go to the compile tab of the project properties and click Build Events

Insert this as the POST BUILD EVENT

ilmerge /target:winexe /out:"$(TargetDir)$(ProjectName)$(TargetExt)" "$(TargetPath)" "$(ProjectDir)Mono.Cecil.dll"

Notice that the OUT parameter specifies the output file name via the $(ProjectName) variable (which is still “GenerateLineMap”) while the first assembly to merge is specified using the $(TargetPath) variable (which is the full filename of the output assembly, including the “-Interim”).

EDIT: Important note: Notice the /target:winexe option. You’ll need to change that as appropriate depending on the type of exe you’re building. In my case, I had a console app where this needed to be set to just /target:exe. Setting it to /target:winexe caused all of the console output functions to just do nothing, which threw me for a bit!

Now, just rebuild the solution and you should see two resulting EXE files in your output folder, one with the “–Interim” (which is the version WITHOUT the embedded Mono.Cecil.DLL file or whatever DLL you’ve chosen) and one WITH the embedded file. As a final cleanup, you may want to add an additional Post build step to remove the “*-Interim” files.

To test, just make sure you DO NOT have the embedded DLL anywhere on the path or in the same folder as the exe and run the exe. If everything went right, your app should work exactly the same as if the embedded DLL was included externally with the app!

Now, your application is back to being a single EXE to distribute, and it was built completely automatically by Visual Studio.

Caveats

You knew there had to be some, right?

The first is that if the dll to embed contains licensing information, it might not work properly after being embedded. I don’t have any DLLs like that to test with, but I’ve read reports about the problem at various sites on the internet. Just something to be aware of.

Second, trying to replace the originally named exe with the newly built one results in VS not being able to debug the exe in the IDE (it throws a message about the assembly manifest being different from what was expected). I haven’t worked that issue out yet. What this means is that you might need to leave any references set to “Copy to Output Folder” while debugging, and not replace the original compiled assembly, just ILMerge it into a new assembly name.

If you haven’t checked it out already, DirectShowLib.net is pretty much THE way to get at direct show functionallity in VB.net (that is unless you want to spend $$$). Thing is, it’s only a paper thin wrapper over the DirectShow COM api stuff, so there ain’t no hand holding here.

I’d mucked with it for a while and with the help of some of the sample code, got video playing in a form in VB.net fairly easily, but, I needed to flip and/or rotate that video under some circumstances.

After many googles, I finally came across the IVMRMixingControl9 interface that the VideoMixingRenderer9 exposes, but, no matter what I did, I could not cast from a VMR9 to the MixingControl, like so:

Dim Mixer = DirectCast(VMR9, IVMRMixerControl9)

I kept getting an “Interface not implemented”. Then I happened across a post about a wholly different problem, but buried within it was a comment about needing to set the VMR into “mixing mode” in order for it to implement that IVMRMixingControl9 interface. Ugh! DirectShow is nothing if not interfaces. And odd dynamically implemented interfaces at that. Oh well.

A little more digging, and it turns out to be quite easy. Just obtain the IVMRFilterConfig9 interface from your VMR9 object, and call SetNumberOfStreams on it (with and argument 1 or more).

The end result is code that looks like this (remember, this is with a reference to DirectShowLib.net):

DIM FGM = New FilterGraph
Dim VMR9 As IBaseFilter = New VideoMixingRenderer9

FGM.AddFilter(VMR9, "Video Mixing Renderer 9")
Dim FC As IVMRFilterConfig9 = VMR9
FC.SetRenderingMode(VMR9Mode.Windowed)
FC.SetNumberOfStreams(1)

Dim Mixer = DirectCast(VMR9, IVMRMixerControl9)
Mixer.SetOutputRect(0, New NormalizedRect(1, 1, 0, 0))
Mixer.SetAlpha(0, 0.2)

Note that in this case, the SetOutputRect is reversing the output rectangle, so the video is going to end up flipped and upsidedown, exactly what I was needing. I’ve also set the alphachannel to .2, meaning the video is somewhat transparent.

Unfortunately, there doesn’t appear to be any way to rotate the video using the MixingControl, so that is my next topic of research.

A long (long) time ago, if you wanted your users to be able to enhance your product by add coding logic, you pretty much had two choices:

• Dig into Lex and Yacc or....
• Roll your own parser and scripting execution engine.

Then, around the time VB 6 was released, Microsoft introduced VBA. It worked, but it was expensive and a god awful complicated mess to integrate with your app, so outside of Microsoft Office (which even as of Office 2010, still supports it!), very few applications actually made use of it.

Around the same time, the Microsoft Scripting Control was released. This was an ActiveX control you could use from any COM compatible language to embed VBScript. Now, of course, this is VBScript, not a "real" language like C or even VB. But, it was free, easy to obtain, and very easy to use.

As the years have rolled by, .NET has steadily grown in capability and while the Windows Scripting Host exe is still shipped with Windows, the old VBScript and JScript scripting has largely been supplanted by either:

• ASP and more recently ASP.NET
• Powershell
• Dynamically compiled .NET code
• and likely lots more options I'm not familiar with

Now, all these options are good, and each definitely has it's place, but, for many purposes, good ol' VBscript still fits the bit quite nicely.

But can you use it from .NET? And if so, how?

The Tempest in the Teapot

Before I continue, I should point out that any time you start talking about allowing users to add their own code into your application, you're opening up a huge can of worms that you'll need to deal with. Things like properly catching exceptions from badly written user code (yeah, that never happens), adding watchdog timers to deal with hung and infinitely looping user code, security concerns, and the like all will have to factor into the decision. You have been warned .

So Simple It Hurts

I had a plugin project recently where I wanted to give the user the ability to write some very simple logic to expand the functionality of the application.

Of course, I wanted to build a full plugin API, but I also wanted to provide a lighter-weight option for those users that didn't want to dive head-first into a full on .NET project. VBScript seemed like the obvious choice.

A few Google searches later and most everything I found was talking about how to dynamically compile .NET code, which is cool indeed, but not what I was really after. Other articles and posts insisted that users should convert their VBScript code to .NET (ok, yeah, but that's not really the point now is it?).

Then I did a Google Desktop search of my own system and turned up some VB6 code I'd written ages ago to experiment with the Microsoft Scripting Control.

Now, I know that .NET languages support accessing ActiveX Controls and COM objects in general, but this was pretty old stuff. Would it actually still work?

I cobbled up a dirt simple VB.net project:

Public Sub Main()
    Dim Script = New MSScriptControl.ScriptControl
    Script.Language = "VBScript"
    Script.AddCode("sub Main" & vbCrLf & "MsgBox ""This is a Test"" " & vbCrLf & "End Sub")
    Script.Run("Main")
End Sub

Be sure to add a reference in the VB.net project to the COM object "Microsoft Scripting Control".

Run it, and lo and behold, I get the "This is a Test" message box, straight from VBScript!

Obviously, there's lots more to making use of the Scripting Control than just this, but, clearly, VBScript is still very much a choice for adding limited programmable logic to your application.

I've been working on getting MSBuild setup and configured to handle some Continuous Integration builds for our company. One task that came up was needing to get a large batch of files from our TFS server and pull them down to the appropriate directories on a local machine.

But here's the catch. I didn't want to just pull everything  from those folders down. Some folders contain very large files that didn't really need to come down at all, because the intent was that the build process would be building them.

So, it would have been relatively easy to use the MSBuild Extensions pack to get all the files recursively in my project.

    <Target Name="GetInstallFileSet">
        <MSBuild.ExtensionPack.VisualStudio.TfsSource TaskAction="Get" ItemPath="..\InstallFiles" WorkingDirectory="$(MSBuildProjectDirectory)" Recursive ="true" Force ="true" />
    </Target>

The WorkingDirectory parameter indicates where TFS will base all relative file specs from. The ItemPath indicates the folder location (relative to where the MSBuild proj file is located that this Target is in) that TFS should retrieve. The TaskAction of GET just retrieves all files in that folder, and the Recursive parameter tells TFS to get all files in that ItemPath and all it's subfolders.

Pretty simple, but if there were large files anywhere in the path, TFS will obligingly retrieve them as well, which could suck up a lot of time and bandwidth.

So, first, how to specify only those files that I really want to retrieve? Easy, just use an ItemGroup.

    <Target Name="GetInstallFileSet">
        <ItemGroup>
            <InstallFileSet Include="..\..\Install;
                                     ..\..\Install\System;
                                     ..\..\Install\OtherFiles;
                                     ..\..\Install\DiskSet">
            </InstallFileSet>
        </ItemGroup>
    </Target>

The InstallFileSet ItemGroup will end up with these specific folder names (all relative to the path to the proj file the target is defined in). Unfortunately, I don't see any straightforward way to "leave out" specific files, because using any wildcard specs when defining this ItemGroup would be based on files that already exist on the local workstation, and hence we run the risk of NOT getting newly added files that exist in TFS but not locally.

But, if those files happen to live in specific subfolders, we CAN leave out those subfolders from the list in the INCLUDE attribute of the Item definition above.

Ah, but what about recursion? In the above case, I specifically DO NOT want to recurse down from the first path in the list (..\..\Install), but I DO want to recurse on all other paths.

That's where the 'metadata' aspect of MSBuild comes into place. Modify the ItemGroup slightly.

    <Target Name="GetInstallFileSet">
        <ItemGroup>
            <InstallFileSet Include="..\..\Install>
                <Recurse>false</Recurse>
            </InstallFileSet>
            <InstallFileSet Include="..\..\Install\System;
                                     ..\..\Install\OtherFiles;
                                     ..\..\Install\DiskSet">
                <Recurse>true</Recurse>
            </InstallFileSet>
        </ItemGroup>
    </Target>

Notice that I've split the InstallFileSet item into two pieces, and added the Recurse attribute to each piece.

Now, all the items are still in the single InstallFileSet ItemGroup, but one has a Recurse property of false, the others have it set to true.

Using the ItemGroup

All I have to do now is indicate how to use the ItemGroup that I've defined

...
        <MSBuild.ExtensionPack.VisualStudio.TfsSource TaskAction="Get" ItemPath="@(InstallFileSet)" WorkingDirectory="$(MSBuildProjectDirectory)" Recursive ="%(InstallFileSet.Recurse)" Force ="false" All="true" />
    </Target>

Adding this one TaskAction="Get" line will no perform the Get from TFS on all those Items.

So I ran the build, and... Fail.

TFS gave me a "parsing" error on the ItemName argument. Apparently, it doesn't like being passed a long list of semicolon delimited path names.

Gah. This is where the UnBatching comes in.

Batching Explained

As a build engine, MSBuild will generally try to "batch" multiple items together into one processing "call", so that as few invocations of that call as possible are made, under the assumption that fewer invocations will be faster.

Unfortunately, in some cases, you really don't want the processing batched. In this case, batching would cause multiple paths to be supplied to one invocation of TF.exe (the TFS client app), which, as I mentioned, doesn't know how to deal with that.

The key to understanding batching is MSBuild will batch by default, but will separate out batches based on two things

1. Any metadata attributes associated with the batch items
2. How you reference the items in the batch.

1) is easy. In the above example, I've got two values of the metadata tag "Recurse", so MSBuild by default will execute the GET task twice, once, with the Item(s) with Recurse=true, and once for those with Recurse=false.

But 2) is harder to grok. As it is now, I'm using ItemPath="@(InstallFileSet)" to reference the itemgroup. That allows MSBuild to batch the items, but then it splits the batch by the Recurse attribute.

However, if I reference the items by the built in identity metadata tag, MSBuild will consider each item in the group has having unique metadata associated with it, so it will execute the GET task once for each item, do that by using %(InstallFileSet.identity) instead, as in:

...
        <MSBuild.ExtensionPack.VisualStudio.TfsSource TaskAction="Get" ItemPath="%(InstallFileSet.identity)" WorkingDirectory="$(MSBuildProjectDirectory)" Recursive ="%(InstallFileSet.Recurse)" Force ="false" All="true" />
    </Target>

If you build now, you'll notice that the TF.EXE process is launched once for each path in the InstallFileSet ItemGroup, and that the Recurse attribute is applied appropriately depending on which item is being processed.

Conclusion

MSBuild is definitely powerful. In some ways, it's simpler to deal with than the MAKE/NMAKE systems of old, and the source proj files are definitely more flexible in how they can be used.

But, many of the more advanced functions (that you'll end up needing quite quickly) can leave you scratching your head. And the available documentation and examples often don't help much.

The key is patience and experimentation.

I've been working with .NET and Office interoperability for some time now, and, other than a few minor hiccups here and there, things have generally been very smooth.

But a colleague recently ran into a problem that required a good deal of hunting to resolve. Long story short, even though .NET interoperability with Office objects is virtually foolproof, releasing your references has some hidden dangers lurking amongst the weeds.

As a general rule, it's safe to let the .NET garbage collector (GC) do it's thing while your application is running.

BUT, when you're app shuts down, you need to take a few extra steps to make sure everything's cleaned up before quitting.

The details are laid on in this article on MSDN. It's from 2005, but, from what I can tell, it's just as applicable now as it was then.

Essentially, the trick boils down to this:

When you're preparing to shut your application down, you need to make SURE you've released all your references to any Office objects. This means setting all your various references to Nothing, or, more typically, letting the GC do its thing.

Unfortunately, the GC doesn't necessarily do its thing during a shutdown, so you have to force the issue. And that requires code essentially like this:

WordApp.Quit() 
WordApp = Nothing 
GC.Collect() 
GC.WaitForPendingFinalizers() 
GC.Collect() 
GC.WaitForPendingFinalizers() 

The article noted above doesn't really go into why it's necessary to call Collect and WaitForPendingFinalizers twice, but it does appear to be required. I'm guessing it's due to the way the Finalizer sweeps object references; it could be possible for it to release objects in a certain order, causing it to skip some objects. But that's just a guess.

And as a final note, if your .NET code uses any COM interoperability, it might be a good idea to do some final cleanup along these lines as well.

Billy Hollis has out an interesting article in the latest Visual Studio Magazine about the possible destiny of Agile Development.

(sidenote: what the hell has happened to VBPJ VSM? Am I the only one that remembers the days when that mag was just shy of a phonebook and literally every article was worth the read? This latest issue is barely enough paper to wipe your a$s! Seriously. It's sad).

Anyway, Hollis calls out Agile Dev fans, sort of. He takes a bit of a middle of the road stance, which, actually, I find quite refreshing. To me, Agile has always seemed more like a tactic to avoid really learning to improve your craft and rather, just plowing forward, balls-to-wall to get something working, dammit! It kind of reminds me of a quote I once read supposedly from Steven King. When asked what his process was for writing books, he said something like "I just keep flailing away at the damn thing till I have something I like."

Now, don't get me wrong. Getting something working is important. But the more I look at the tenets of Agile, the more I wonder whether it's really the consultants recommending it and the experts teaching it for 1000$ a day that stand to gain anything from it. It just sounds like yet another in a long line of silver bullets.

The best line from Hollis's article is:

Most developers love to write code, and agile does a pretty good job of rationalizing why developers don't need to do anything else.

Ouch!

I ran into a chunk of code today that threw me.

The code was contained within a particular class definition.

Every member (properties and methods) were marked Shared.

Public Shared Sub MyMethod()
blah....
End Sub

The net effect was a class that, even if you could instantiate it, wouldn't have any purpose as in instance. Its sole use was to provide essentially a dumping ground for a bunch of general purpose library routines.

At first, I just wrote this off as odd and continued on.

But, on further reflection, this just doesn't seem right. As Scott Hanselman might say, it's got a rather nasty Code Smell.

So, I did what any reasonable person would do; I googled it.

Apparently, there are more than a few people out there contemplating the same thing. What's scary though, is that usually, the arguments end up along these lines:

1. Modules in VB.Net are a throwback, a hack, and a nod to compatibility and should be avoided.
2. Modules can't be accessed from other .NET languages.
3. Other .Net Languages don't have modules, so you're better off using shared members on a class definition.
4. Modules aren't OOP. Classes are. Use classes.

It's already been proven that, internally, VB.Net modules compile to exactly the same code as a Class with shared methods. Further, the modules have been documented as a first class feature of VB.Net, the language, not some soon-to-be-deprecated nod to VB6 compatibility. And Modules CAN be accessed from other languages. So I'm not going to bother with any of those bits again.

Personally, I think in comes down to two simple concepts, syntactics and semantics.

The Syntactics

Syntactically, defining members in a Module allows them to be accessed without  qualifying the member with the module name. So, given this Module definition:

Public Module MyModule
   Public Shared Sub MyMethod()
      blah....
   End Sub
End Module

I can access the method MyMethod by simply invoking the name MyMethod(); I don't have to qualify it, as in MyModule.MyMethod().

This is a minor issue, except that it effectively allows you to extend the VB language. You can add your own RIGHT() function or LEFT() function, etc. This can be a fantastic aid to code readability when used appropriately.

The Semantics

However, I believe the even bigger argument is semantics. A class, is, by its very definition, the definition of an object that can be instantiated. Even singleton classes can be instantiated at least once. But a class of shared methods is a class that has no reason to be instantiated. And that really isn't a class, it's just a set of loosely related, if even related at all, functions. And that is the definition of a Module!

Do you regularly create an integer type variable when what you really need is a DATE? Then why collect a bunch of shared functions in a class when a module is specifically intended for such purposes?

Discoverability

The only rational I can come up with is discoverability. Forcing developers to prefix shared methods with the class name provides a means (through Intellisense) of discovering the capabilities of that class. But, you can optionally prefix module members in exactly the same way, so again, shouldn't we be using the features of the language as they're intended?

Why Shared Members at all?

Given this, what benefit is there of using shared members at all?  I've seen a few examples for defining singleton objects where you retrieve the single instance via a shared member of the class. That certainly makes logical sense, but from a coding perspective, it seems ugly to me. Why ask the class for the single available instance of itself? Shouldn't you ask something else for that instance? It also makes for some odd-reading code:

Dim TheOneInstance = MySingletonClass.GetTheOneInstance

And other than singletons, what other purpose is there for shared members?

(UPDATE 10/29/08: After further experiments and reading, it turns out that, as far as I can tell, the ONLY way to truly get a singleton object is to use a shared method within the object itself. Nasty, but that appears to be the only way to do it).

I know the .NET framework uses them extensively, but are they used effectively?

For example, take the String class. It exposes quite a few shared members, such as Compare and Copy. But in practice, using those shared members doesn't quite make sense. If I'm comparing two strings, the object-oriented thinker in me naturally gravitates to:

If OneString.Compare(OtherString) Then

Not

If String.Compare(OneString, OtherString) then

The bottom line is, if I'm comparing two strings or copying a string, I'll always be working with an instance of a string, so why shouldn't those methods be instance methods and not shared methods?

I suppose String.Format() is a passable example, but even that would seem to make more sense as:

dim x = "Insert a parameter here {0}".Format(Arg0)

Do you have a good use for shared methods that you'd like to, uh, share?

Let me know!

We recently got into a discussion where I work about the best way to explain to a user why a control is disabled.

One person argued that it made sense to leave the "disabled" controls enabled, and, when a user tried to click/use the control, pop up a messagebox explaining why it won't work in this instance.

To me, that seemed to go against everything I'd ever learned about UI design and controls, namely, if a control is disabled, it ought to look disabled on screen and it shouldn't do anything if you poke at it.

Still, I'd had plenty of experience myself with apps where controls were disabled and I had no idea why they were disabled, much less how to go about getting that functionality enabled. That can certainly make for a frustrating time.

Then someone suggested a tooltip or a status bar message. If you tried to click the disabled control, or hovered your mouse over it, you'd get a little, innocuous message somewhere telling you why that control was disabled.

Awesome idea!

Only one problem.

Tooltips don't work for disabled controls. Actually, they do for menus, toolbars and likely a few others, but that's another story.

And you don't get MouseOver events on disabled controls.

Sigh.

Well, I couldn't just walk away from this.

A quick google turned up a few bits:

• There was this from Roy Auchterlounie, but it's MFC.
• But then there was this nugget from a post by Linda Lui, apparently with MS Support. It's in C#, but it's relatively easy to translate to VB.

The only thing was, Lui's solution was not exactly what I'd call an encapsulated solution.  As Scott Hanselman would say, dropping snippets of code like this all over my forms just doesn't have a wonderfully fragrant code smell.

I'd messed around with Control Extenders under ASP.NET some time ago, and this seemed like the perfect excuse to try it out on a good ol' WinForms app.

A little refactoring later, and I've ended up with the "Disabled Tool Tip" Extender Control. It directly inherits from the out-of-the-box tooltip in VS2008. As a result, there's not a lot of code here. Also, it should work with VS2005, but I'm not guaranteeing as much.

Add this class to your project, recompile, then drop one onto a form.

Zip! Boom! Pow! Every control on your form should now have a "ToolTip on DisabledToolTip" property. You simply set this new property to the tooltip you want to show when the control is disabled and you're done.

(my test rig, she is much fine, no? )

A few notes about this class.

One significant issue I ran into immediately, was how do you retrieve a reference to the containing form if you're a component sited on that form. All the obvious stuff didn't work. There's gotta be a more straightforward way to do it, but I failed to find it, at least with respect to a Component type control (one of those that isn't actually sited ON the form, but rather in that little area at the bottom of the designer).

I ended up caching an instance of some control during the SetToolTip method, since this method is called during the form initialization by any control on the form that had a tooltip set for it via the designer.

   Public Shadows Sub SetToolTip(ByVal control As Control, ByVal caption As String)
      MyBase.SetToolTip(control, caption)

      '---- if we don't have the parent form yet...
      If rParentForm Is Nothing Then
         '---- attempt to get it from the control
         rParentForm = control.FindForm
         '---- if that doesn't work
         If rParentForm Is Nothing Then
            '---- cache the control for use a little later
            rControl = control
         End If
      End If
   End Sub

But, you can't use the FindForm method here, necessarily, because if the form is still being initialized, you'll get back nothing.

So, I ended up implementing the ISupportInitialize interface, and, during the EndInit method, if I have a cached control reference, I use it at this point to retrieve the parent form via FindForm.

   Public Sub EndInit() Implements ISupportInitialize.EndInit
      '---- if we weren't able to retrieve the form from the control
      '     before, we should be able to now
      If rControl IsNot Nothing Then
         rParentForm = rControl.FindForm
      End If
   End Sub

Roundabout, yes, but it seems to work in a very stable way, and it means I don't have to resort to MFC style subclassing and the like. I can just monitor events on the parent form via a simple WithEvents variable reference.

Anyway, the full code for the class is here. It's short enough that I'm not going to bother with a ZIP file at this point.

And finally, as with any code you pick up off the net, I'm making no guarantees of any sort. If it works for you, great. If not. Well, I'll certainly do my best to help if you let me know. It works for me, but it is necessarily full on, battle tested, bulletproof stuff? Uh. No.

Enjoy! If you see any improvements to be made, please share!

And please, if you post it elsewhere, give me (and Linda Lui) proper credit!

Imports System.ComponentModel

''' <summary>
''' Custom ToolTip Component that is based on a normal tooltip component but tracks tips 
''' for disabled controls
''' Note that the because this is a separate extender, all the controls on a form
''' can have an "Enabled" tip (as normal) AND a "disabled" tip.
''' 
''' By Darin Higgins 2008
''' Based on a code example by Linda Lui (MSFT)
'''
''' </summary>
''' <remarks></remarks>
''' <editHistory></editHistory>
Public Class DisabledToolTip
   Inherits ToolTip
   Implements ISupportInitialize

   '---- hold onto a reference to the host form
   '     to monitor the mousemove
   Private WithEvents rParentForm As System.Windows.Forms.Form

   Private _rbActive As Boolean = True
   ''' <summary>
   ''' Active for the Disabled ToolTip has a slightly different meaning
   ''' than "Active" for a regular tooltip
   ''' </summary>
   ''' <value></value>
   ''' <remarks></remarks>
   <DefaultValue(True)> _
   Public Shadows Property Active() As Boolean
      Get
         Return _rbActive
      End Get
      Set(ByVal value As Boolean)
         If _rbActive <> value Then
            _rbActive = value
         End If
      End Set
   End Property



   '---- hold on to a control temporarily while we wait for things to 
   '     settle
   Private rControl As Control

   ''' <summary>
   ''' Shadow the settooltip function so we can intercept and save a control
   ''' reference. NOTE: the form MIGHT not be setup yet, so the control
   ''' might not know what it's parent is yet, so we cache the the first control
   ''' we get, and use it later, if necessary
   ''' </summary>
   ''' <param name="control"></param>
   ''' <param name="caption"></param>
   ''' <remarks></remarks>
   Public Shadows Sub SetToolTip(ByVal control As Control, ByVal caption As String)
      MyBase.SetToolTip(control, caption)

      '---- if we don't have the parent form yet...
      If rParentForm Is Nothing Then
         '---- attempt to get it from the control
         rParentForm = control.FindForm
         '---- if that doesn't work
         If rParentForm Is Nothing Then
            '---- cache the control for use a little later
            rControl = control
         End If
      End If
   End Sub


   Public Sub BeginInit() Implements ISupportInitialize.BeginInit
      '---- Our base tooltip is disabled by default
      '     because we don't want to show disabled tooltips when
      '     a control is NOT disabled!
      MyBase.Active = False
   End Sub


   ''' <summary>
   ''' Supports end of initialization phase tasks for this control
   ''' </summary>
   ''' <remarks></remarks>
   Public Sub EndInit() Implements ISupportInitialize.EndInit
      '---- if we weren't able to retrieve the form from the control
      '     before, we should be able to now
      If rControl IsNot Nothing Then
         rParentForm = rControl.FindForm
      End If
   End Sub


   Public Sub New(ByVal IContainer As IContainer)
      MyBase.New(IContainer)
   End Sub


   ''' <summary>
   ''' Monitor the MouseMove event on the host form
   ''' If we see it move over a disabled control
   ''' Check for a tooltip and show it
   ''' If the cursor moved off the control we're displaying
   ''' a tip for, hide the tip.
   ''' </summary>
   ''' <param name="sender"></param>
   ''' <param name="e"></param>
   ''' <remarks></remarks>
   Private Sub rParentForm_MouseMove(ByVal sender As Object, ByVal e As System.Windows.Forms.MouseEventArgs) Handles rParentForm.MouseMove
      Static ctrlWithToolTip As Control = Nothing

      Dim ctrl = rParentForm.GetChildAtPoint(e.Location)

      If ctrl IsNot Nothing Then
         If Not ctrl.Enabled Then
            If ctrlWithToolTip IsNot Nothing Then
               If ctrl IsNot ctrlWithToolTip Then
                  '---- if we're not over the control we last showed
                  '     a tip for, close down the tip
                  Me.Hide(ctrlWithToolTip)
                  ctrlWithToolTip = Nothing
                  MyBase.Active = False
               End If
            End If
            If ctrlWithToolTip Is Nothing Then
               Dim tipstring = Me.GetToolTip(ctrl)
               If Len(tipstring) And Me.Active Then
                  '---- only enable the base tooltip if we're going to show one
                  MyBase.Active = True
                  Me.Show(tipstring, ctrl, ctrl.Width / 2, ctrl.Height / 2)
                  ctrlWithToolTip = ctrl
               End If
            End If

         ElseIf ctrlWithToolTip IsNot Nothing Then
            '---- if we're over an enabled control
            '     the tip doesn't apply anymore
            Me.Hide(ctrlWithToolTip)
            ctrlWithToolTip = Nothing
            MyBase.Active = False
         End If
      ElseIf ctrlWithToolTip IsNot Nothing Then
         '---- if we're not over a control at all, but we've got a
         '     tip showing, hide it, it's no longer applicable
         Me.Hide(ctrlWithToolTip)
         ctrlWithToolTip = Nothing
         MyBase.Active = False
      End If
   End Sub
End Class

Way back in the wild west days of VB6, if you wanted a long running utility to ALSO pop up a progress bar, be cancelable, and be nicely encapsulated in a reusable class, you didn't have a lot of options.

The first was to actually use VB6's multithreading support via a thread per object ActiveX exe. It worked, but it wasn't a trivial exercise.

One trick I used on a number of occasions was the modal form callback.

Essentially, it works like this.

• You call into a class to "start" the long running process.
• The class opens an associated progress form, and passes itself to the form.
• The Progress form stores a WithEvents reference to the class, so it can be notified of progress as the class does its work.
• Then, the form shows itself modally, and in the Activate event, calls back into the class to actually start the processing.
• The class then starts it's long running processing, raising progress events as appropriate, and yielding via DOEVENTS at appropriate times.

It's a tad complex, to be sure, but certainly less complex than some of the alternatives and it still yields a nicely responsive UI that the user can easily cancel out of.

Fast forward to today. I had a similar requirement for a little VB.NET utility, so I figured, what the hey, might as well use that old trick.

After a bit of coding, I run the app and am rewarded with this:

Huh? I wasn't "Attempting to call into managed code without transitioning out first." Heck, there wasn't even any API calls in this mix, Much less "Low Level extensibility points"!

Of course, the VS help for this message proved utterly useless, so I start googling.

Equally useless. Surely, I'm not the only guy out there to get this treat, right?

Anyway, eventually, I decided that maybe, just maybe, something about the reentrancy into the class from a modal dialog was causing the problem, though I still don't have concrete proof of that.

I reworked the class to cooperate with the BackgroundWorker component (a nifty little bit of new .NET goodness), and everything's back on track.

The only bit of nastiness left is that my background worker class raises several events, which my progress form monitors and presents, but doing anything within those events directly resulted in an exception about accessing UI objects from a thread other than the one they were created on.

The VS Help was helpful for this though, and adding code like this to the event handlers...

   Delegate Sub ScanningFileCallback(ByVal FileName As String, ByVal Count As Integer)
   Private WithEvents MyClass As MyClass

   Private Sub MyClass_ScanningFile(ByVal FileName As String, ByVal Count As Integer) Handles MyClass.ScanningFile
      If Me.prgProgress.InvokeRequired Then
         Dim d As New ScanningFileCallback(AddressOf MyClass_ScanningFile)
         Me.Invoke(d, New Object() {FileName, Count})
      Else
         me.prgProgress.Maximum = MyClass.FileCount
         me.prgProgress.Value = Count
      End If
   End Sub

worked around that problem nicely, although it'd be nice if the background worker class could somehow handle this transition itself. Hmmm....

I've always been a big fan of the MZTools addin for VB6, so it was a little disappointing, if not understandable, that for his .NET foray, he's wanting to get paid a little something for it.

Not that that's bad, I just haven't been able to commit to MZTools for .NET just yet.

In the meantime, I stumbled across a very slick little VS addin called DPack.

It's actually a small set of different addins. Doesn't look like you get the source, which is unfortunate, but the features are pretty slick, plus they work in VB, C++ and even C# and Ruby.

The Code Browser alone is worth the download. With one keystroke, you get a window like this:

It's nicely sorted, browsable, and with one other click, takes you directly to the given code element. Even better, you can assign direct keystrokes to filter only methods, classes, properties, etc. By default, ALT-M shows just the methods in the current file, for instance. Reminds me of the old F2 (Function list) key that used to be in older VB's. I missed that key<sob>.

Also particularly nice is the "Surround Selection With..." feature. You can't customize the surrounding text but they give you the most common items (surround with TRY CATCH, FOR NEXT, DO WHILE, REGION, etc, etc.), so that's not too bad.

It seems very quick and stable. And the best part is, it's completely free!

A recently posted article on CodeProject had this to say about Visual Studio's support for multi-lingual applications:

Conclusion: Visual Studio .NET does not offer any multilanguage support which is worth thinking about it.
You will only waste your time with Microsoft's approach!

Check the whole article/project out here.

I can't verify the author's credentials that would justify such a claim, but from the sound of it, he did at least start down the MS sanctioned path, and I have to agree with him.

Way back in the dark ages, pre-internet, around 1990 or so, I was managing development of a CRM system (customer relationship management software).

We'd picked up some resellers oversees and needed to get the product internationalized. This was really at the very beginning of Windows even (Win 3.1 and WFW, if you remember those!). Our internationalization efforts had to apply equally well to our DOS app and our Windows version.

Several of the developers and myself went to a conference, the precursor to VBits, (I don't remember exactly what it was called back then) and I got a chance to talk with one of the MS internationalization engineers directly.

I'd played with the whole "separate resources for each language" technique and found it workable, but so labor intensive, that I couldn't imagine anyone but the largest shops actually doing it that way.

The MS guy verified that suspicion. He said (and I'm paraphrasing), "The core team finishes up the project, and ships it, and then the whole project base is 'thrown over the wall' and each internationalization team then takes over and internationalized the project into their respective languages, re-tests, etc."

Ouch.

Now, I'm sure times have changed at MS, but if the comment from Elmue in the article on CodeProject is any indication, they haven't changed that much.

The internationalization functions I helped build way back then was based on 3 simple concepts:

1. The original english strings had to remain in the code
2. Those strings has to actually be used by the code
3. Those strings had to be easily searchable (say, by a GREP or similar utility) for extraction and translation

Why those first two points?

Because if the english strings remain in the code, the code remained relatively easy to debug and maintain for the programmers.

Further, if the strings are actually used by the code, that meant that during dev and alpha/beta testing, we wouldn't have any disconnect issues with resources not matching what was needed in the code itself. This is akin to the age old concept of eating your own dog food. The idea of socking strings away in resources and just having a comment in the code as to what the string contained just scared the hell out of me.

Also, it also meant that if the translatable resources are lost for whatever reason, the program would still be able to run based on the "compiled in" English strings. Not ideal, but better than simply throwing errors or displaying blanks.

We accomplished all these goals by embedding all translatable strings (including those in dialogs, etc), into a function call. Something like:

MyString$ = TX$("This is the english version", stringcode, groupcode)

Where stringcode and groupcode were optional arguments that indicated, basically, the resource ID of the string and an arbitrary group ID of the string.

Originally, when you were writing or working on code, you'd never even bother entering the stringcode or groupcode args, so your call would look like:

MyString$ = TX$("This is the english version")

But, because it was trivially easy to scan for TX$(), when our scanner was run on the code, it could

1. Extract the strings
2. Give then ID's
3. Rewrite the source code with the appropriate string and group codes as necessary.
4. Generate a "translator's file" that contained the string, ID's and potentially developer comments that would indicate the context of the string and intention (for use by translators to assist with the translation).

Nowadays, with OO, extension methods, reflection, and all the other .NET goodies, seems like this whole process could be vastly more efficient than even what we did back then.

But in the end, we translated the product into 8 or more languages in just a few months with this technique, using no additional developers, and a few native speaker volunteer translators. And it didn't require any code rewrites and was just as efficient to debug as if you'd left the strings in the code and did nothing about translation at all.

Now, granted, there's a lot more to internationalizing an app that translating text. You have to worry about icons, input method (when applicable), date, time, and number formats, and even subtle things like color choices, but it was a huge timesaver for an otherwise arduous task.

Closing comment: Why TX$() you might ask ? Basically, it was because we didn't want a huge function name taking up tons of space in the code when it would be used as often as it was. That's all. As I recall, it is about the only two letter function I've ever authored in code. I was never a big fan of the BASICA 2 letter name restriction!

Any translation war stories out there? How have you translated applications?

I'm constantly amazed by some of the goofy things that application installations do to my system without even giving me the option.

Obviously, there's the whole spyware/adware problem, but that's just blatant.

There's an entirely other, more subtle, level to the problem, where applications do little things that are difficult to undo, are annoying and that you aren't given the option of not "doing" in the first place.

Here's one example. Now, I like the CodeJock products, and I'm not really picking on them here, it's just that they give me a good example:

This is the "Right Click - New" menu that you get from Explorer when you right click in a folder and select "New".

Now, I'm a pretty busy developer, and I like a nice shortcut just as much as the next guy, but honestly, I can't imagine EVER creating so many "Command Bars Designer Documents" that I'd want an entry for it on my New Items menu like this. As you can see, there's already enough junk on this menu. I wonder how many people out there create a new contact, bitmap image or briefcase so regularly that it belongs on this menu. Hell, I've always created new Word docs by opening Word, starting my document and then "File-Save"-ing them wherever, never by the "New Office Word Document" menu, but then, maybe that's just me.

A few others:

• Unrequested shortcuts on the QuickLaunch space or the Desktop.
• Unrequested Tray Icons.
• Adding Vista Sidebar gadgets without permission.
• Stealing file extension associations without asking and not restoring them on uninstall.

Any other bits of application rudeness out there anyone has run into?

First, I should say I'm a pretty ardent supporter of VB, even VB.net. Heck, that should be obvious from the name of this blog

But, as I'm getting more and more into the ".net" of VB, I'm finding more and more things to dislike about it.

There's plenty already written on this subject and maybe I'm a tad late to the party, but I haven't seen these particular things mentioned before, so here's my additions to the topic.

• Sluggish IDE. Good god. I've got a dual core Core2 rig with ultrafast video and 4gb of ram, and the VS2008 IDE feels like trudging through a Valdez-soaked beach compared to working with VB6. I understand this isn't specifically a VB problem. The IDE applies to all .NET languages. But that doesn't change the fact that if you program in VB, you use the IDE, and it's a dog.
• Intellisense. I like Intellisense, the concept, but there's just something about the VB.NET implementation that is so much more "in the way" that VB6's. It feels a bit like that brother-in-law that you can't get off the couch soon enough...
• MDI style IDE. While there are definitely some improvements to the UI of the IDE, and just maybe I'm a relic, but I MUCH prefer the VB6 (and before) "SDI" floating windows style IDE to this monolithic, MDI style environment. To make good use of it, you have to maximize it on-screen, which hides everything else onscreen. Granted, a nice dual or triple monitor setup minimizes that impact, but still, I just find it much more cumbersome and "in the way" than the old environment.
• Uninitialized strings variables. This one just floors me. Take this code:
      dim s as string
      debug.print len(s)
      debug.print s.length
  The len(s) line works like you'd expect (you get 0), but the s.length line fails with an error! What the hell? An uninitialized object? This is like a car manufacturer coming out with the new year model and swapping the gas and brake pedals. I don't care whether they told me about it before or not, it's just plain stupid. Why on earth have two functions that do exactly the same thing but one works as any longtime VB programmer would expect and one does not? And no, "That's just the CLR/it's necessary for C#/Blah Blah" just doesn't cut it.

As I read through many of the posts, I have to admit I've started to wonder myself as to whether this is all some low-level ultra-subtle manipulations on the part of MS to nudge people further and further away from VB. Yes, it starts to sound like conspiracy theory, but surely, all this couldn't be completely unintentional, could it?

Even so, there are ways around some of this. And I still much prefer VB, the language, to anything even resembling C and it's ilk.

Still, if no one complains, things won't change (or they'll get worse<sigh>).

String manipulation is a very different beast in VB.NET than in VB6. In fact, I'd wager that it's the one area that trips up programmers new to VB.NET more than any other aspect of the language.

I've talked about some annoying aspects of System.String before, but this go round, I'm going to concentrate on shared methods.

Shared Methods are methods that are invoked via the class type itself, and not via an instance of the class.

For instance, with strings, you have a nicely named IsNullOrEmpty  function that you'd expect would return a true/false indicating whether the string in question is null or empty. Unfortunately, you'd be only half right.

Bring up the Object browser and find the String class, then highlight the IsNullOrEmpty method and you'll see this:

Notice the Shared keyword. That indicates that this method IS NOT an instance method, thus you can't invoke it via a specific instance of a string; rather, you must invoke it via the String class directly.

So, you can't do this:

Dim s as string
If s.IsNullOrEmpty Then

But you can do this:

Dim s as string
If String.IsNullOrEmpty(s) Then

Now, it makes perfect sense, from a purely technical perspective, that invoking an instance method on an uninitialized object wouldn't work anyway, so a method like IsNullOrEmpty wouldn't make sense to be an instance method, since attempting to invoke it via a variable that hadn't actually already been initialized would result in an "Object not Set" error.

However, this is VB, not some ivory tower exercise in theoretical language design. If I'm going to invoke a method like IsNullOrEmpty, I’m expect to be able to do so against an instance. Having to invoke it via the String class is just so utterly unintuitive, it defies all reason.

Oddly, the very argument that I note above in favor of using a shared method for IsNullOrEmpty is violated by another string property, Length. Here's a property that is definitely an instance property, but causes VB code to fail (with the Object Not Set error) when invoked on a variable that hasn't actually been set to value yet.

Is this just an arbitrary oversight, a design flaw, or an intentional "feature" of the language? I can't answer that.

But, realistically speaking, I can say that it's utterly frustrating to have elements of a language, such as these, behave so drastically different from one version to another. It doesn't matter that the syntax is different (x.Length vs Len(x), for instance), there is an expectation there that simply is no longer met and does nothing but confuse.

Fortunately, with VB 2008, there is a relatively trivial way to correct these problems, and likely a host of other similar issues.

It's called "extension methods".

To create an IsNullOrEmpty that works like any reasonable person would expect it too, just put this in a Utility module somewhere in your project:

Imports System.Runtime.CompilerServices

Module StringExtensions

    ''' <summary>
    ''' Returns True if the current string instance is nothing or a null string
    ''' </summary>
    ''' <param name="aString"></param>
    ''' <returns></returns>
    <extension ()> _
    Public Function IsNullOrEmpty(ByVal aString As String) As Boolean
        Return String.IsNullOrEmpty(aString)
    End Function
End Module

The Imports System.Runtime.CompilerServices is only used during compilation. You can actually continue to target the .NET runtime v2.0, even if you use this code (however, you still have to compile the code from VS2008, it won't work in VS2005).

You tag the new version of IsNullOrEmpty with the <extension()> attribute to  mark it as an extension method.

The first parameter of an extension method is required and is an argument of the type of class that you're extending, in this case the String class.

You can have additional arguments if necessary, but you don't need any for this method.

This trick takes advantage of the fact that even though the String class already has a method named IsNullOrEmpty, the function signature is not the same as this one (since ours has the implicit first argument). This is effectively an overload and it allows VB to know to call the new method if invoked against an instance, and the old one if invoked against the String class directly (which is exactly what's being done within the method itself!).

There are several other "shared" methods on the string class that can similarly be extended to more intuitive instance methods in this way, for instance:

• Compare
• Concat
• Format
• Join

Length could also be added to this list but you can't quite treat it the same, since it's a property, and the Extension attribute can't be applied to properties.

Finally, extension methods can be unbelievably useful for associating functionality with specific classes that you can't extend in any other way, but, as always, you need to be careful with how much you extend a  class.

For example, it might be tempting to extend the String class with all sorts of path/file/folder manipulation and parsing logic, so that you could do something like this:

dim s as string = "c:\myFolder"
debug.print s.DriveLetter

but doing so could quickly clutter the String object and Intellisense.

As usual with these sorts of techniques, use judiciously.

Some time ago, (or here in the wonderfully virtual web world), I questioned the whole aspect of all this pile of controls in ASP.NET. Of course, you've got the grids and listviews, and you also have all the radio buttons, checkboxes. But then you've got a separate validator for each kind of validation you want to use, and even validators to let you combine other validators in "AND" and "OR" logical relations.

My thoughts were "Jeez. this is madness."

Wouldn't a single control that you could adapt to different display behaviors, validation rules etc be much easier to work with and create a more maintainable solution?

Well, apparently someone at Microsoft had the same bright idea, at least with the new ListView control in ASP.NET 3.5.

Take a read of Fritz Onion's article in the latest MSDN magazine.

He describes the new ListView as a control that can "literally replace all other databinding controls in ASP.NET. That's right. Every last one."

Now, if they'd do the same for that validation nonsense, we might be getting somewhere!

I've started playing more and more with .NET lately. There's a lot to like, a lot to dislike, and a few things that left me scratching my head.

One is this new fascination with moving regional (or class scoped variables) up to right on top of the properties that are wrapping them.

You've no doubt seen the pattern.

In old school VB6, you'd have something like this:

    {top of class}
    Private _MyPropVar As Boolean

    {lots of code here}

    Public Property Get MyProp() As Boolean
        Return _MyPropVar
    End Get

    Public Property Let MyProp(Byval NewValue as Boolean)
       _MyPropVar = value
    End Set
    {code continues}

And in the New Order, you have this:

    {other code}

    Private Shared _MyPropVar As Boolean = True
    Public Shared Property MyProp() As Boolean
        Get
            Return _MyPropVar
        End Get
        Set(ByVal value As Boolean)
            _MyPropVar = value
        End Set
    End Property

    {code continues}

Now, the pundits out there claim that the ability to move the definition of the variable that stores the property value down in the code to where the property is actually defined is a good thing.

And it very well might be.

But if that variable is used elsewhere in the class (it is, after all, visible to the entire class), then it makes more sense to me for it to be grouped with other such class scoped variables at the top of the class, and not buried within the class.

What's most frustrating about this, though, is that the language designers had the perfect opportunity to solve this problem elegantly, and didn't.

The simple introduction of a property scope would have done the trick. Then for those variables that are ONLY used to track the contents of a property, you'd have this (note the _MyPropVar definition has moved to INSIDE the property declaration):

    {other code}

    Public Shared Property MyProp() As Boolean
        Private _MyPropVar As Boolean = True
        Get
            Return _MyPropVar
        End Get
        Set(ByVal value As Boolean)
            _MyPropVar = value
        End Set
    End Property

    {code continues}

Now there may be significant ramifications involved that prevented this change, and I'm certainly no expert at compiler design or implementation (though I have implemented a pseudo-code compiler scripting language used in a commercial product).

But this just doesn't seem like all that big a deal to have implemented and would have cleanly resolved where to put variables of both persuasions (ie those that are used by ONLY a single property, and those that are truly class scoped and used my multiple properties/methods).

Personally, I think this was a bit of a "good enough" decision.

Practically, I think I'll stick with locating truly class-scoped variables at the top of the class, and ONLY bury variables that really are only accessed by a single method/property.

I'm guessing that the vast majority of VB apps (VB6, or .NET), have no public interface. After all, VB is the prototyping language, not an actual project development language, right? </sarcasm>

Well, if you do eventually find yourself in need of exposing a public interface from your application, what's the right way to do it?

First, a definition, though.

By public interface, I'm talking about some manner of exposing functionality within your application to the outside world. What you do with your BAS files, and private CLS files, not to mention FRM's, or the all-encompassing  VB.NET *.VB file is your own business. But what the world sees, or, more appropriately, has to deal with, is another matter altogether.

There's a pile o' ways to expose functionality from an app, especially a VB app.

First, a few old school methods....

• DDE - Yeah, it's still alive. Want proof? Just boot up a copy of Vista, load REGEDIT and search for DDEEXEC in the HKCR hive. But seriously, you don't want to go there.
• Windows Messages - SendMessage/PostMessage. They're not just for subclassing and peeping toms. DDE and even COM relies on the Window Messaging subsystem to work. Your apps can leverage it too. But really, that's a whole lot of pain for not a lot of gain, so why bother?
• DLL Entry Points - There are several tools out there that make exposing DLL entry points from a VB application relatively easy to do. In some cases, this is how you have to expose functionality (as in when some other app only makes calls to DLL entry points, and you want that app to talk to yours). But using this technique to expose your own functionality to the world just seems so, well, reagan-omic.

And the more common techniques....

• COM - The classic VB PUBLIC class. All you gotta do is change your class's interface type to PUBLICNOTCREATABLE, MULTIUSE, or GLOBALMULTIUSE and biff boom pow! Anyone can use your class, right?
• .NET Assemblies - Same as COM, but shinier

OK, COM (or .NET assemblies) it is (I'm going to consider the two the same for now, what sacrilege!)

So how do you do it?

There's piles of books on the mechanics of the task, so I'm not going there. Just look at Kurata's Doing Objects in Visual Basic 2005 or Dan Appleman's various books on ActiveX techniques for those kinds of details.

What I'm talking about is which interface design is most appropriate.

Kinds of Interfaces

Generally, I've seen these designs gather into 3 camps:

• The massive wad of hierarchically related objects. This is the Outlook, Word or Excel object models.
• The single public class containing all the functions you could ever want. Not terribly common; I see it most is 3'rd party utility libraries.
• And finally, the single class with a single (or at most very limited set of) functions that serve as a "command line" of sorts where you might pass in a parameter that is the "operation" and that additional parameters that are the "arguments for the operation". The GroupWise API is a great example of this.

The Massive Hierarchical Wad

Pros

• Easiest to program against. Intellisense, separate objects, etc speed working with your model.

Cons

• Hardest to keep compatible. Even minor changes from one version to the next of your application can render it incompatible with previous versions of your application, causing loads of headaches for your users.

The Single Class

Pros

• Relatively easy to program against. Intellisense will help. So does consistent naming of all those methods and properties.
• Works well for relatively minor amounts of exposed functionality.

Cons

• Generally considered bad practice.
• Suffers from compatibility headaches much like the Massive Wad.

The Command Line Class

Pros

• Essentially immune from direct interface compatibility issues, since the lone interface is flexible enough initially to never have to be changed.

Cons

• More difficult to code against. Intellisense only helps with the command line function itself, not with each of the commands that can be sent.
• Moves compatibility issues to the user. If new functions are introduced, it's the users responsibility to test for the version of the application and react appropriately.

So, what's the final word?

As usual, there's really no right answer.

Personally, I tend to stay away from the "Single Class", simply because it has all the difficulties associated with the Massive Wad, and none of the immunity of the Command Line Class; the worst of both worlds.

The Command Line Class is most useful when your exposed function points number in the 10-100's. Any more than that, and it starts to become unwieldy, though it's still perfectly workable.

The Massive Wad is the most traditional, most familiar style of public interface to those who've likely used public interfaces of other systems. That's not to say it's the best option, just that's it's the most typical.

How about it? What kinds of public interfaces have you built and put out there? Is there a style I've missed. Maybe something better than any of these?

Here's a little trick I'm not sure many people know about, but that I've used for so long, I'd basically forgotten about it.

I wrote about overriding the ERR object in VB here, and also wrote a far more involved article about it.

But did you know you can also override the MSGBOX function?

Just create a function with the following signature in a BAS module of your choice:

Public Function MsgBox(ByVal Prompt$, Optional ByVal Buttons As VbMsgBoxStyle = vbOKOnly, Optional ByVal Title$ = "", Optional ByVal HelpFile$ = "", Optional ByVal Context As Long = 0) As VbMsgBoxResult

Put the appropriate code in it, and presto, custom msgbox.

Why, you might ask?

• Personally, I like the option of logging every msgbox that's displayed by my app. Errs are handier, but msgbox's can be useful.
• In addition, you have the option of calling the MessageBox API call directly yourself, which gives you access to additional flags that you can't use with the VB version alone.
• You might also decide that the MSGBOX proper just doesn't look good, and craft up a modal, nicely skinned form to stand in its place.
• And finally, in a particular app I worked on, I needed to call a function BEFORE and a different function AFTER displaying every msgbox. I certainly didn't want to alter every call to MSGBOX and add those extra lines. Overriding it made that a trivial task.

Please let me know if you come up with any good uses for this trick.

I've been trying to make a point of reading more .NET code lately.

Maybe it's Scott Hanselman's Weekly Source Code.

Or maybe it's that Code Project gadget on my Google home page.

At any rate, I just ran across a project there call LinFU (don't ask what it stands for), but...wow.

It reminds me of the Black Belt columns by Matt Curland ages ago in Visual Basic Pro (or whatever it was called then, now Visual Studio Magazine). There hasn't been articles like his in that rag for years. (and btw, if you still do VB6 and don't have his Advanced Visual Basic 6, I'd highly recommend getting a copy).

Anyway, it's stuff like Philip Laureano's LinFU that really is making .NET seem more and more attractive.

It seems like such a simple task; check a variable for whether it contains a true value or a false value.

No problem, right? Well, if you're dealing with numbers, maybe, but when input comes from config files or databases, the truth <ahem> may not be so obviously out there.

As part of my code garage, I thought I'd post two functions I've used for ages to do just that; convert a variable, virtually any variable, to a boolean result.

They are especially useful in configuration handling, where you might want to support multiple values that might mean "true" or "false", like on/off, yes/no, etc. I've also found that they can make code clearer by specifying the "assumed" default value if the variable can't be concretely identified one way or another (is "Bob Thomas" true or false?).

Public Function IsTrue(VarToTest As Variant, Optional ByVal Default As Boolean = True) As Boolean
   '---- Resolve an input variable to a boolean
   '     but convert common "true"/"false" phrases as well
   '     Also, this allows for an easy way to indicate a
   '     "default" value in cases of an undetermined (ie blank)
   '     value
   Dim t$
   Dim s

   Select Case VarType(VarToTest)
      Case vbArray
         Err.Raise 5, "IsTrue", "Can't test an array for true"
      Case vbObject
         IsTrue = ObjPtr(VarToTest) <> 0
      Case vbString
         If Len(VarToTest) = 0 Then
            '---- is true assumes blanks are true
            IsTrue = Default
         Else
            On Error Resume Next
            '---- strip to first space
            t$ = Trim$(Left$(VarToTest, 15))
            s = InStr(t$, " ")
            If s > 0 Then t$ = Left$(t$, s - 1)
            '---- clean out any tabs
            t$ = Replace(t$, Chr$(9), vbNullString)
            '---- accept some synonyms (any other good ones?)
            If InStr(1, t$, "YES", vbTextCompare) = 1 Then
               IsTrue = True
            ElseIf InStr(1, t$, "NO", vbTextCompare) = 1 Then
               IsTrue = False
            ElseIf InStr(1, t$, "ON", vbTextCompare) = 1 Then
               IsTrue = True
            ElseIf InStr(1, t$, "OFF", vbTextCompare) = 1 Then
               IsTrue = False
            ElseIf InStr(1, t$, "TRUE", vbTextCompare) = 1 Then
               IsTrue = True
            ElseIf InStr(1, t$, "FALSE", vbTextCompare) = 1 Then
               IsTrue = False
            Else
               IsTrue = CBool(VarToTest)
               If Err Then
                  IsTrue = Val(VarToTest) <> 0
               End If
               On Error GoTo 0
            End If
         End If
      Case Else
         If IsEmpty(VarToTest) Then
            IsTrue = Default
         Else
            On Error Resume Next
            IsTrue = CBool(VarToTest)
            If Err Then
               IsTrue = Default
            End If
            On Error GoTo 0
         End If
   End Select
End Function


Public Function IsFalse(VarToTest As Variant, Optional ByVal Default As Boolean = False) As Boolean
   '---- basically, the inverse of IsTrue above
   '     mainly for convenience

   IsFalse = Not IsTrue(VarToTest, Default)
End Function

   If IsFalse(SettingValue) Then 
      '---- handle the negative condition here
   End If

just seems so much clearer.

The optional Default argument allow you to specify what value to return if the value to test can't be resolved satisfactorily one way or the other. Practically, this allows you to easily specify whether a blank value or a "non-boolean" value should translate to true or false. This is especially important when you're reading config options from a file or the registry where the option may not exist at all.

It allows to do something like so: 

   If IsTrue(SettingValue, False) Then 
      '---- handle positive conditions here, but if the SettingValue is blank, we default to False
   End If

No, I don't do Don Henley impersonations. But I was starting a load of laundry the other day and something struck me. Once I'd recovered and put the broom back where it was supposed to be, I realized something.

Take your standard, run of the mill washing machine. It's essentially a variable speed motor, a few belts and pulleys, a water pump, and big cog timer wheel that sort of looks like the sheet music for a player piano*.

These things will run several times a week, for years on end and only rarely have any issues. Even then, the most likely problems are things like belts wearing out, bearings getting squeaky, or the timer cogs breaking off causing cycles not to start or stop properly. Further, I'd be willing to bet that just about anyone can set one up, plug it it, connect the 2 water hoses and the drain line, and be doing laundry within 30 minutes to an hour, and just about never think about any of that "configuration and setup" again till they move. 

Compare that, then, to the lastest washing machines, with "steam" cleaning, LCD consoles, touchscreens, dozens of "operating modes", delay start timers, and even internet access.

I love gadgets, but seriously, does being internet-enabled or using an LCD touch screen get my clothes any cleaner, or prevent me from actually having to lug my laundry to the utility room? Do they actually save real people any time whatsoever over a 200$ (or cheaper) model with knobs instead of touchscreens and mechanical timers instead of microchips? Is this really progress?

I gotta stop hitting myself with brooms.

* and yes, that's an oversimplification, for all you washing machine enthusiasts out there.

Ok, nothing to do with Visual Basic, but, you gotta come up for air sometimes!

It's been a while since a video game really wowed me.

I mean, there's lots of slick 1st person shooters out there now and with some of the heavy iron running around now, the graphics can make "Toy Story" almost look like "Dragon' Lair."

Still, nice graphics only go so far. And 1st person shooters are starting to see a little stale.

Then I stumbled into Grid Wars 2. Holy cow. I mean, seriously.

World of Stuart summed it up thusly in his review; "THIS is a video game."

Go there for some wicked screenshots (far better than what I've put up here) and a link to download. You can't get it from Marc Incitti's site anymore <sigh>. Apparently, it's a bit too much like "Geometry Wars" for the comfort of its creator. Grab your copy while you can.

I've never played it's progenitor, but Grid Wars 2 definitely brings the frenetic back to video games. Plus, some subtle scoring tricks that WOS discusses in his writeup that make it all the more interesting. And there seems to be no end to the unique powerups that pop (get 150 bad guys, 3 black holes, 4 snakes, with quad cannons, side fire, fast fire and bouncing shots going all at once, and you'll swear your screen is about to catch fire).

And, come to think of it, there is a little bit of VB goodness here, or rather BASIC goodness. It's opensource, and written in BlitzMax, a pseudo-basic, game programming platform form Blitz Research. Plus, the install is unbelievably sweet. A zip file. Just unzip somewhere and run the EXE. T'would be a blessed day that Office trod down that path.  

Here's another handy bit from my VB6 code shed out back.

If you've worked much with databases in VB6, you know that you almost always end up having to deal with database NULLs at some point.

And, in VB6, the only variable type that can actually deal with nulls is the Variant.

For the most part, my code avoids nulls by coercing them to the most appropriate "null value", either a 0, or a 0 length string, etc, depending on the underlying data type.

However, there are instances where I've needed to compare two values directly from the database, and didn't want to coerce them up front.

That's where this handy routine comes in.

Public Function CompareVariant(Var1 As Variant, Var2 As Variant, Optional CompareMethod As VbCompareMethod = vbBinaryCompare) As Long
   '---- Compare 2 variants that might contain NULL or empty values

   Dim bVal1Null As Boolean
   Dim bVal2Null As Boolean
   Dim bVal1Empty As Boolean
   Dim bVal2Empty As Boolean
   Dim bSameValues As Boolean

   bVal1Null = IsNull(Var1)
   bVal1Empty = IsEmpty(Var1)
   bVal2Null = IsNull(Var2)
   bVal2Empty = IsEmpty(Var2)

   '---- variants are the same if
   '     1) both are null
   '     2) both are empty
   '     3) they are otherwise equal
   If (bVal1Null And bVal2Null) _
      Or (bVal1Empty And bVal2Empty) Then
      CompareVariant = 0
   Else
      '---- you can only check for equal values is if neither of the values is Null or Empty
      If Not (bVal1Null Or bVal1Empty Or bVal2Null Or bVal2Empty) Then
         If CompareMethod = vbTextCompare Then
            CompareVariant = StrComp(CStr(Var1), CStr(Var2), vbTextCompare)
         Else
            If Var1 > Var2 Then
               CompareVariant = 1
            Else
               CompareVariant = (Var1 < Var2)
            End If
         End If
      ElseIf bVal1Null Then
         '---- This is arbitrary, I'm determining that NULL is < empty
         '     this might not be universally appropriate, though
         CompareVariant = -1
      Else
         CompareVariant = 1
      End If
   End If
End Function

Basically, the idea is similar to the built-in VB function StrComp, but it intelligently deals with potentially NULL or empty variants as well.

Are there faster ways to do this? Probably. But I find I need the functionality so infrequently, it hasn't been a priority to optimize.

Still, if you need it, coding this up each time would be a complete pain in the ass (and unfortunately, I've seen that tack taken more than a few times).

If anyone can improve on this, please let me know!

I'm thinking of starting an ongoing series of posts highlighting some of the more "interesting" things you can do with VB6 that are not, at least to my knowledge, particularly well known. I figure, VB6 has started on that long slow road into SNOBOL-dom, the land where old languages go, not necessarily to die, but to continue living, just with very few people paying any attention. We can only hope C and C++ will head there eventually.

Anyway, might as well collect a few of my favorite hacks, tweaks, and WTF?! bits before they all end up only in the depths of the WayBack machine. 

Here's one that you don't see often. If I remember correctly, there is a bit of a performance hit with it, but it's pretty minor.

Did you know a VB module can actually contain properties?

Huh, you say. Interesting, but so what?

Well, since public elements of modules are public project-wide, you can create some pretty handy functions this way.

For instance, say you have a function to read an entire text file in at one shot, and one to write a whole text file. You could have two subs to do the dirty work. Or you could do something like this (put this code in a BAS module, not a class):

Public Property Let FileTextContent(ByVal FileName$, ByRef NewValue$)
   '---- Block write the entire file's content in one shot
   Dim fh
   
   On Error Resume Next
   fh = FreeFile
   Open FileName$ For Output As fh Len = 2048
   Print #fh, NewValue$;
   Close #fh
End Property


Public Property Get FileTextContent(ByVal FileName$) As String
   '---- Block read the entire file's content in one shot
   Dim buf$
   Dim fh
   
   On Error Resume Next
   fh = FreeFile
   Open FileName$ For Binary Access Read As fh Len = 2048
   buf$ = Space$(LOF(fh))
   Get #fh, , buf$
   Close #fh
   FileTextContent = buf$
End Property

With a property like this in place, you can then read a file's content with Just:

x$ = FileTextContent(MyFile$)

Which looks exactly like a function call, granted. But you can write a file's content with:

FileTextContent(MyFile$) = x$

It's a minor syntactic difference from just using two subs, or maybe a sub and a function. But personally, I think it reads a little nicer.

Of course, you can also use this technique to provide for global scope properties, ie properties that don't belong to any particular class. This is sometimes handy when you need to expose a value globally, nut you also want to perform some processing on it during an assignment or a retrieval.

You could define the global property via a GLOBAL variable definition, but that gives you no "hook" to do your processing on the value when code retrieves it or sets it. Instead, use something like this in a BAS module:

Private rMyProp as long
Public Property Let MyProp(Byval NewValue as long)
   '---- Block write the entire file's content in one shot
   
   'DO YOUR CODE HERE
   rMyProp = NewValue
End Property

Public Property Get MyProp() As Long
   
   'DO YOUR CODE HERE   
   MyProp = rMyProp
End Property

Now, you have a convenient way to get and set the value from everywhere in your project, AND you have point at which you can hook in to preprocess or post-process the value as necessary.

And, if you name the module something short and sweet, say, like UTILITY, then you'll get handy intellisense as well (just type "UTILITY." to get the props and functions available on it).

What's with this?

I've seen this term bandied about, usually referring to some new feature in VB, and usually in a disparaging way.

Why?

I thought pretty much everything about a 3 or 4GL was syntactic sugar. Without that sugar, we'd be coding in assembler or hex opcodes. I mean, an IF THEN ELSE construct is just syntactic sugar for a bunch of JNEs or JEQs, right? Hell, object oriented code is nothing but syntactic sugar for an array of type structures and function calls with an index as their first argument (the hidden ME pointer in all OO compiler code).

Sounds more like just so much L337ism to me.

I say bring it on. As long as it makes sense, expands the language in useful ways, and isn't required to make use of the language, the more the merrier. My only concerns would be:

• Any additional syntax that's required in order to successfully use the language. That's VB.NET's biggest problem now, with respect to adoption by users of VB.
• Compatibility breaking changes

Still, I think ANDALSO is a tad corny, nice, but corny. So shoot me.

VB6 has the interesting capacity to compile to either native code or pseudo-code.

Native code is actual Intel machine code. Pseudo-Code is much like the .NET "Intermediate Language" or IL, although, I suspect, a little less refined<G>

Most VB6 programmers I've known tend to compile to Native code although pseudo-code can be quite handy in some circumstances. First, it compiles much faster. Second, the generated EXE's or DLL's are typically much smaller than Native code EXE's or DLL's.

But what if you want, or need, to tell the difference at run time?

You could write up a conditionally compiled constant, but then you have to remember to switch the condition when appropriate. Still, that's probably the ideal way to go.

But, that's not really  a runtime solution, now, is it.

I happened upon the solution ages ago when I was researching an article I wrote for VBPJ about implementing TRY CATCH exceptions in VB6.

Essentially, you grab the first byte pointed to by a function pointer and check it. If it's an &HA1, you're in the IDE running pseudo-code.

If it's &HBA, you're running as compiled pseudo-code.

Anything else means you're running compiled native code.

As far as I can tell, this technique works regardless of optimization settings, etc.

Yeah, it's probably a little overkill, but that's what hacking is all about. Plus, knowing whether you're in the IDE without scrambling the state of the ERR variable is quite handy in some circumstances. I created a separate function for that purpose.

Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (lpvDest As Any, lpvSource As Any, ByVal cbCopy As Long)

Private Function pGetAddr(addr As Long) As Long
   '---- utility function for IsNative and IsIDE

   pGetAddr = addr
End Function


Public Function IsNative() As Boolean
   '---- determine whether we're running
   '     a Native code EXE, or a PsuedoCode exe
   '     Also can determine whether we're in
   '     IDE or not
   '
   '     Now this is HardCode!
   '
   Static Inited As Boolean
   Static bIsNative As Boolean
   Dim b As Byte

   If Not Inited Then
      CopyMemory b, ByVal pGetAddr(AddressOf pGetAddr), 1
      Select Case b
         Case &HA1
            '---- In IDE
            bIsNative = False
         Case &HBA
            '---- Psuedocode compiled
            bIsNative = False
         Case Else
            '---- native code Compiled
            '     the actual byte might be any number of things
            '     because of optimizations in use
            '     but will generally be either &H55, &HC7 or &H83
            bIsNative = True
      End Select
   End If
   IsNative = bIsNative
End Function


Public Function IsIDE() As Boolean
   '---- determine if we're running in environment
   Static Inited As Boolean
   Static bIsIDE As Boolean
   Dim b As Byte

   If Not Inited Then
      CopyMemory b, ByVal pGetAddr(AddressOf pGetAddr), 1
      '---- &HA1 means we're in the IDE, else we're not
      bIsIDE = (b = &HA1)
   End If
   IsIDE = bIsIDE
End Function

The web as we know it is in its death throws.

Um, right.

I just read the Guest Opinion in the latest Visual Studio Magazine. It's by Rockford Lhotka, who I have a lot of respect for. But this piece was a little off.

He basically claims that "the web as we know it is finally coming to an end". Why, you may ask?

• Is it the impending rollout of IPV6?
• Maybe some new 3d "navigator" (as in the-chess-set-on-the-millenium-falcon 3d, not yet-another-2d-window-into-a-virtual-3d-space 3d)?
• Or maybe there's a new "brain driven" interface I hadn't heard of?

No.

It's Silverlight. and Atlas.

Sigh.

According to Rockford, AJAX is the "last gasp of a dying technology". He argues that at some point, "either the browser transforms into a full blown programming platform or we find another answer", and that answer, apparently is SilverLight.

Now, don't get me wrong. SilverLight is pretty slick, as long as you don't try to find any examples of actual web apps written in it. You know, the kind that people would use as opposed to just play with for 5 seconds. There's tons of nice animated displays synched to music and pretty graphics of pages flipping, but where's the data driven samples, or the reporting grids, or the company dashboards, etc?

Not only that, but hasn't the web already got a "launch point to load something that is a programming platform". I thought it was called Flash? And flash has certainly not brought the end of the Web nigh. Hell, it's harder and harder to find sites that even bother with it anymore.

And SilverLight is from Microsoft, so you can bet that, even if they initially support a plethora of browsers and systems, eventually, it'll get whittled down to Windows Voyeur (or whatever they'll be calling the new version in 5 years).

Rockford makes a good point about technologies lasting upwards of around 10 years before being replaced by newer, better concepts. Things like COM, Win32, and CORBA. Things like ISA, the serial and parallel port, and ATA IDE. Things like hard drives, mice, qwerty keyboards, text files and relational DBMSs.... Oh wait.

I'd lay money that the next "big thing," the thing that "kills the web as we know it" and ushers in a new era similar to the internet age of the 90's, will not come from a big house like Microsoft, or IBM, or even Xerox. It'll come from some dedicated hacker like Marc Andreeson or Bram Cohen. It'll start off small. Hardly anyone will use it, kinda like Google back in, oh, 1999. And it'll probably have a goofy name, nothing as cleanly futuristic as "SilverLight".

Until then, I'd say the odds are long on HTML, Javascript, Ajax, etc, going poof.

The VS 2008 VB will support nullable types.

Simply put, a nullable type is a standard type, like, say, integer or string that can ALSO contain a null.

This can become very important in database work, because a null value in a field means that no value has been assigned to that field vs a common case where you might use 0 in a numeric field to indicate no value, or you might use a null string (ie a string with no length) in a string field.

Obviously, using 0 to indicate no value works much of the time, but, there often comes a point when you actually do need to use a 0 value for that field.  There's a number of other, more arcane reasons that using one of the values from the range of possible values of a type to indicate null is usually not a good idea.

Hence, nullable types. With a nullable type, I can have an integer variable that can be a 31bit positive or negative number, or 0, and STILL have yet another "state" of that variable that indicates it's null.

This will likely be incredibly handy for many many uses when working with database data.

But the syntax?

Dim a As Integer?

or

Dim a? As Integer

No, I'm not making that up.

What the hell? A question mark?

Why not just:

Dim a As Nullable Integer

I find this to be an unbelievably hypocritical decision given the almost overwhelming philosophical rants delivered by Microsoft about not using the traditional VB type specifier characters in .NET anymore (you know, $ for strings, % for integers, those bad boys). Heck, check page 42 of "Framework Design Guidelines" by Krzysztof Cwalina and Brad Abrams of Microsoft:

DO NOT use Hungarian notation (their bold, not mine)

Now, to be fair, the authors in this particular instance are discussing publicly available interfaces, but I've seen the same directive applied to internal coding as well. So, we're not suppose to use hungarian, and we're not supposed to use type characters, so we're left to simply scan the code to information about how a variable is used or what it likely contains. Jeez. How convenient.

I've noticed something a bit peculiar about fonts and programmers.

There's the camp that's thoroughly researched the topic, experimented with piles of fonts and ended up selecting one that they can be quite vocal about.

And then there's the camp there never changes the default that came setup in the IDE they installed.

I guess I come from the former. Courier? No way. Arial? Ack! Programming in a variable width font just seems, so, ewww. I was a good, old fashioned FixedSys man for ages. It was decent, had a nice fixed width, slightly too bold, but I could live with it, came with every copy of windows and was pretty legible across all the common characters. But about a year ago, I embarked on a quest to find a better font.

Many, many downloads later, I believe I've ended up with the best of the options out there. The freely available ones, anyway.

I've taken screen snapshots of all fonts at approximately 14pt size. I used 14pt because it's the most comfortable size for me.

I've also included a snapshots of the better fonts at different sizes, so you can get a feel for how they scale.

Bitmap fonts

I'm not a big fan of the bitmap fonts (the FON files). They don't scale well except where they've been defined at multiple sizes (not really scaling), and don't believe they take advantage of ClearType, certainly not very well. Still, there are some interesting bitmap fonts out there.

Most of the good ones are intended to be used as very small fonts. If you have eagle vision, some of them might work quite well. But my eyes would jump screaming from my their sockets if I tried to program in some of these all day.

	10x20-iso8859-1.fon	Not bad but it doesn't scale. Some elements bleed too much.
	9x15-iso8859-1.fon	Too thin for me
	9x18-iso8859-1.fon	Also too thin
	BSUKermit.FON	Base size is too small. Doesn't scale
	Dina.fon	Base size is too small. Doesn't scale
	DOSLIKE.FON	Not bad, but it doesn't scale. Has a few too many serifs for my taste.
	GwdTE_437.fon	Base size is too small. Doesn't scale
	Hyperlt.fon	Actually called HyperFont LT
	IBMPC.fon	10pt. Yikes. Quite small.
	IBMPC.fon	14pt. This is what happens when bad fonts scale.
	PROFONT.FON	12pt. Too small, and the letters bleed together at this size.
	PROFONT.FON	14pt. Way too thick at this size, plus kerning is wacked.
	Raize.fon	10pt. Not too bad, but too small for me.
	Raize.fon	14pt. There's just something about the letter shapes at this size that don't feel right.
	Sysmono.fon	As close to 14pt as I can get with this font.

True Type Fonts

I prefer the true type fonts. They scale well all the way down to about 7 points, but they can take advantage of ClearType, and a few are even specially designed to make optimal use of it.

	Arial.ttf	14pt. Just for reference, a variable width font just doesn't work for me and programming.
	Aerial Mono.ttf	14pt. Pretty good. Seems a bit too bold.
	Andale Mono.ttf	14pt. Quite good. This one was in the running for a while.
	AnonymousRegular.ttf	14pt. Yikes, serifs and programming just don't mix.
	AnonymousRegular.ttf	11pt. Smaller size, same serif problems. I do like the zero, however.
	Bitstream Vera Sans Mono.ttf	14pt. Excellent font. Maybe just a tad too bold, but this one was also in the running.
	Consolas.ttf	14pt. Excellent all around.
	Consolas.ttf	10pt. For reference. Scales well.
	Everson Mono Unicode.ttf	14pt. Very good, but the letters seem to be a bit thinner than numbers and symbols, which looks odd to me.
	Fixedsys.ttf	14pt, note this is the TTF version of the FixedSys font, not the bitmapped version. It's too heavy for me.
	HyperFont.ttf	14pt. Not bad but similar problems to Everson Mono.
	Larabiefont Bold.ttf	14pt. Wow. Those zeros. oh, wow. Screams l33t!
	Letter Gothic Line.ttf	14pt. This one's not too bad, but check out the lower case m's. Funky.
	Monaco.ttf	14pt. Excellent font. Originally from the Mac. the parens are a little odd, but this was definitely in the running.
	PixelCarnageMonoTT.ttf	14pt. Hmm, seems small for 14pt. Decent, but not right for me.
	ProFontWindows.ttf	14pt. The "u", "n" and "c" threw me. This is just a little too "programming in the FUTURE.. FUTURE.. FUTURE.. FUTURE".
	ProggyCleanTT.ttf	Intended to be used small. Ouch, my eyes!
	Reader Sans Roman.ttf	14pt. Funky horizontals.
	Terminal.ttf	12pt. Decent, available, a bit thick in general.
	Terminal.ttf	8pt. Fine if you don't mind going blind at 30.
	Ti92Pluspc.ttf	14pt. Not bad but a little tall for my taste. Any shorter, though, and it gets too thin.
	Topaz-8.ttf	14pt. Ugh. Someone actually recommends this?

Finding the Fonts

I found all these fonts through various sites. Googling the font file name should get you where you want to be. I'm not sure as to posting the fonts for download here, so I'm erring on the side of safety. I apologize in advance for making you hunt them down.

The Winner

I chose Consolas in the end, for several reasons:

• It comes with the newer Windows and it's a VERY high quality font.
• The symbols aren't weird, and most of them, plus the parentheses, kind of 'pop', which I happen to like.
• It's got a good slashed zero
• Line spacing is nice. Not too tight or loose.
• It's thick enough to avoid strange looking "thin spots" but not so thick as to be annoying or have characters bleed (like Terminal)
• No pseudo-serifs (like Anonymous) 

I'm sure there's a lot more possibilities out there, but I didn't see them before I quit looking.

If you have a favorite font, let me know. If I can download it, and it's a serious programmer font, I'll add a sample. 

If you tell me you program in Comic Sans, somewhere, out there, a daemon will abend.

I've worked in a variety of positions over the years, including staffing up entire development departments.

One element I usually insist on in new hires is a reasonably solid foundation of knowledge of basic PC hardware and Windows setup (I've generally worked in Windows shops, hence the bias there). Things like hard drive setup, FDISK, formatting, all the way to assembling normal PC components (i.e. box of parts to a working PC).

Granted, these days, it's not particularly cost effective to actually build out  developer machines this way, but it seems to me that generally speaking, developers ought to know their way around under the hood, maybe not at the circuit level, but at least the component level.

Is this expecting too much? Not enough? I could always wimp out and say that it all "depends on the situation." But I'm not talking about specialized hardware or device drivers. I'm talking about general business applications.

Or have computers become more like commercial airliners or helicopters, where the pilots fly, the mechanics fix, and never the twain shall meet?

There's an interesting discussion on SlashDot asking the question of whether we collective programmers should drop the old "80 column" standard that's still so prevalent and go with some larger number, say 132, or, possibly something even bigger.

With the new widescreen displays, this would almost seem to make perfect sense.

But I think I'd side with the majority of posters that 80 columns is more than enough in most situations. Besides that, there are very good reasons that newspapers and magazines don't print articles the full width of the page, but instead create columns. The eye just has a hard time sucking up that much stuff .

In the typical programming book I have, I counted an average of about 74 chars per line (proportional, so the number could vary, though not by much). In the paper back books I checked, I see about 54 chars per line. These are single column books.

80 would seem just about right. Long enough to deal with the typical indentation of a programming language, but short enough to keep you from getting lost on the line.

Besides, other than those lines with long tables or strings of text, why would you create a very long line of code? C is pretty notorious for allowing such nonsense with it's ? operator and inline assignments, but there's very few that would argue those things make the code more readable. VB has it's ":" statement separator, but there are very few instances where I've seen it put to particularly good use.

Convention generally holds that you want to stick to one statement per line. And typical statements should be far less than 80 chars long.

On a related note, I have a few other questions to throw out

• How many spaces should a tab comprise?
• Is it better to program black on white or white on black?
• Do color coded syntax highlighting editors actually help or just distract?
• Should web pages go columnar when the chars per line exceed some number (for instance, browsing full screen on a widescreen monitor)?

For me, it's:

• 3 (2 is too few to be visually distinct, and 4+ takes up too much line space),
• White on Black (with a white background, there's just too much light coming at me. It's almost blinding to run an editor full screen on a 24" widescreen with a white background.
• Not much, although I do tend to color comments in a dimmer color than the rest of the code. Everything else I tend to leave as white text, unless it's a very specific file format. For instance, I have coloring rules for INI files and XML files to highlight the sections, keynames, and element tags.
• Up in the air on this one. On slashdot, maximized, I count about 230 chars per line on my widescreen monitor. They run as a single column and just stretch it out to accommodate the browser. Many news pages simply limit the max width of the page to somewhere around 1024 pixels or so. Here's a typical MSN page maximized on my system:

That seems like a waste to me.

Bill McCarthy has written a very revealing "What's Hot" for the July Visual Studio Magazine. First off, the name of the "version after the next version" of VB (VB 10) is apparently VBx. I have to believe that that's some small homage to VB3 (for those that were around, that was the summer of '93, I still have the 5.25" floppies of the beta)  and the .VBX custom control that was the precursor to VB's OLE custom controls (OCX's) and in many ways, VB's entire concept of classes.

I suppose if it was less than 14 years ago, there might be some confusion over the naming, but, hey, it was 14 years ago, so I'll let that slide .

One minor note here. Bill's article indicates that VBx is the "next version of the VB compiler", which isn't quite true according to this posting on the VB Blog.

Bigger news is that the VB team is rolling out the Interop Forms Toolkit 2.0, which allows you to create OCX controls and integrations with VB6, in VB.NET. Now, as intriguing as this nugget is, it makes me wonder. VB6 is scheduled for End-of-Life in 2008. Introducing such a toolkit so close to that end-of-life would seem to be an implicit acknowledgement that, well, somebody screwed the pooch. This is a pretty clear indicator that, as much as Microsoft would love to see VB6 die, they've come to a realization that maybe, just maybe, people have very good reasons to continue using code that works. Maybe this realization will be the kick in the pants for Microsoft to not pull stupid semantic tricks with future VBs that break all sorts of backwards compatibility, again. Hmmm, and maybe Chuck E. Cheese will one day be a fun place for adults to hang out, too.

But, by far the biggest news to hit me square in the jaw was the VB group's plans to have VB10, er, VBx written in VB itself! For me, this is simply huge. I've always said there are a certain fundamental class of problems a compiler presents that a good language should be able accommodate, and finally, VB will become one of those languages. I for one, have heard one too many times "If VB was any good, it'd be written in VB." 'Bout damn time!

Of course, there's this troubling passage on the blog

"Currently VBx is in very early stages, and is a long way off from production. In fact, most of our development team is actively working on VB 9."

Doh. Well, so VB get's real when I finally get my flying car (that's this one, not this one)

Leave it to MS to come up with the phrase Runtime Agility, but the concept, if I'm understanding it right, is very intriguing.

The post is here, but to summarize, Paul Vick is a lead on the VB team, and is discussing some of the items on the block for VB8.

He off hand mentions this...

"Runtime agility. The ability to compile without a VB runtime, or targeting another VB runtime."

Now, if I'm reading that right, this would seem to be huge. The idea of VB being able to "compile in" the runtime is something I know I've been asking for since VB3. Does it waste a little space? Sure. But it means you can truly have a single EXE "copy and deploy" type scenario.

And does this mean the .NET runtime bits that are necessary will get baked in as well? Too early to tell, I suppose. Still. Something very interesting to watch in the coming months.

Here's an interesting read on something coming down the pike with Visual Studio. Basically, it's a customizable shell of VS that would theoretically allow you to build you're own Visual Studio, language and all.

Likely, it'll be on a complexity scale of integrating VBA into your app (anyone remember that 300-armed, greased-up monster squid?), but still, very interesting.

Another interesting read on Extension Methods coming in VB9. I've wondered why something like this hasn't been in VB since the very early days of classes (anyone remember VB4?). Why, oh, why have I never been able to create a method like:

Public Function MyOwnReplace(Self as string, Arg as string) as String Extends String
      Return Blah(Arg)
End Function

and then use it by calling the function method off of any ol' string variable...

Debug.Print MyString.MyOwnReplace(Arg)

Maybe this is a contrived example, but the Dynamic languages concept of extending existing objects is something that just belongs in VB.

There's an interesting opinion piece by Kathleen Dollard in last month's Visual Studio magazine. The latest issue has another piece by Kathleen that is very similar. There's no link to the latest one, because that issue has just come out (I got mine not 30 minutes ago).

In them, she's essentially saying that the .NET framework, and all the various supporting enterprise frameworks, have become so large that no one can hope to be competent enough in them to be able to intelligently determine what to use, when to use it and when to stay away.

I couldn't agree more. But despite comments in the article that she is "more optimistic today" and that "the revolution has begun", I still come away from the articles sensing a muted dread. Fear that suddenly, skills you possess today and have honed over the years will become worthless. The value of the knowledge you currently have is drying up like last weeks doughnut holes.

And I'm just not down with that.

That fact is, my experiences seem to suggest that the less you know about these high level frameworks, the better off you are. I'm not saying don't get familiar with them. I'm saying that if you spend time to learn the basics of computer functionality, hardware, interfaces, binary, and object oriented principles like encapsulation, polymorphism and inheritance, details of specific frameworks just tend to come out in the wash.

On the other hand, if you spend all your time focusing on a specific framework, when it's no longer de rigeur, you're screwed.

Microsoft has created some great stuff, to be sure, and some of the newest bits out of the pipe certainly seem compelling, WPF probably more so than anything else. But it's also thrown out plenty of red herrings, costing companies untold money before people realized that "the silver bullet of the day" probably wasn't a good idea after all.

Back to the knowledge issue though. When VB1 came out, and only a bit later VB3, everyone exclamed at how great it was because "you didn't have to know the nuts and bolts of the Windows API to get something built for Windows". Which was true, unless you wanted to build an program you could actually do something with.

The fact is, VB was like that first step down into the pool. It lets you get your feet wet and get used to cold water before you dive in headfirst. Plus you get to feel for sure whether there's any water in the pool.

But eventually, you either dive in, or you decide you don't like programming.

VB.Net has always been more like the diving board. You either walk away, or you dive in, and you won't know if there's water in the pool till you feel it or you bash your skull on the gunite.

I think there's a bigger issue here, though. Emphasizing all these layers of Linq, Sharepoint, WPF, WF, WCF, Ajax, and blah blah blah, won't help encourage anyone to dive in, and that's what VB.net needs to be doing. Instead we get, what, the MY classes. Puh..leaze! At least edit and continue finally came back with VS 2005. Where's the genius that decided it'd be a good idea to leave it out in the first VS releases, anyway?

Don't get me wrong. You can create some hardcore stuff with VB.Net, a lot easier than was ever possible in VB. But you get some hardcore baggage coming along for the ride too. And that's unfortunate, because falling CS enrollments may mean a pretty sweet employment future for me, but it bodes some not so sweet prospects for our long term technological advancement as a nation.

And dammit, I want my flying car before I GOTO END !

You are writing all your applications with a Client-Server architecture, right?

Oh, wait, this isn't the late 90's.

You are writing all your applications as 3-Tier assemblies, right?

Oh, wait, this isn't the early 2000's.

You are writing all your applications... Oh, to heck with it.

What's the architecture du jour these days, anyway, n-tier? x-tier? SOA? XYZ-PDQ?

So what's all the hubbub?

I propose something radical. Logically tier your code based on functionality, not locality. If you do that properly, monolithic, Client-Server, 3-tier, n-tier, x-tier, tears for fears, it won't matter.

Why not?

Because if the code is properly organized and logically tiered, you'll be able to easily move it wherever it needs to go to create (and remove) whatever tiers become necessary.

For example, I once worked for a company building a sizable billing package based on SQL Server. We wanted it 3 tier (Presentation, Business Logic, and Data Access), but we also needed it to be:

1. easy to debug and maintain, and I mean easy, not the "learn how to jump through hoops faster" easy, but really easy. The dev team was small. This was a requirement.
2. easy to deploy in a demonstration mode. If a prospect couldn't fire up a CD install and in 5 minutes or less be playing with it, it wasn't going to fly.
3. capable of scale-out deployment to accommodate multiple report generation servers, data analysis servers, etc.

In the end, we designed a server app as the BLL (it actually ran as a service), a database chock full of highly optimized stored procs as the DAL, and a fat client that contained not only the user-facing interface but also the entire server app internally. And the key to all this was that the code for the server was exactly the same code as was in the client. The code was literally shared between projects in our VCS.

When connected to an actual server component, it got all the benefits thereof. But for debugging, it was unbelievably efficient to have both the client and server right there running at one time not only in the same IDE, but actually as part of the same executable. And deployment was a snap because the demo install didn't have to bother with a server installation, it just created the DB and dropped the client on the machine.

If we'd needed to split functionality out farther, it would have been a very straightforward process because internally, everything was already split out.

The bottom line is:

Get the logical tiers right and encapsulate with a vengence.

Note to self: Vengeful Encapsulation. Sweet band name!

Ok, how hard is it really to use a standard Windows button control on a form?

Apparently, for this app, it's pretty difficult (and this is a big name Document Management app):

Notice the FIND and PROFILE SEARCH buttons. They're some kind of odd "flat button" thinggees, but right next door are two standard Windows OK and Cancel buttons (hopefully, the grokked down capture still shows this).

Maybe I'm just nitpicking here, but if you're gonna skin an app and give it new button styles, shouldn't you do all of them? Or just leave em alone?

My question is, Why stop at button styles? Why not make some labels bold, and others italics, just for the heck of it. Consistency is the mother of derision, right? Oh, and throw in some good colors while you're there. It'll help. Trust me.

I once wrote an article about error handling in VB6 for Visual Basic Programmer's Journal (Sept 2001, jeez that seems like a long time ago!). It was born out of the need for a comprehensive framework for handling errors in an app I was working on at the time.

Since then, I've expanded the framework several times and it's grown into something quite handy. Once I get it cleaned up a bit for public consumption, I'll make the new and improved version available.

I've since been looking at the .NET error handler framework, and while it's certainly much improved over the VB6 days, it still leaves a lot to be desired.

At the very core of handling errors is the division of error types into two distinct classes:

• Expected Errors
• Unexpected Errors

In a perfect world, every possible error is an Expected Error and there are no errors that can occur within your program that the code isn't written to intelligently deal with.

At the other end of the spectrum, is, of course, where most textbook and magazine article sample code lies; where every error is an Unexpected Error that will crash the program.

Unfortunately, real world limitations on time, money, manpower, etc tend to force all code somewhere south of Nirvana.

The .NET fanclub used to decry VB's on error goto as antiquated technology, and trumpeted try catch as the silver bullet of the day. And I suppose:

On Error Goto Catch
Try:
...code to try...
Goto EndTry
Catch:
...code to handle any error in the try block...
EndTry:

is quite different from

Try
...code to try... 
Catch ex as exception 
...code to handle any error in the try block... 
End Try

as long as you're only looking at their checksums .

Sure .NET incorporates a wealth of metadata about the exception. The module, function, line number, etc are all available directly while handling the error. But something's missing.

Oh, yeah, What about those Unexpected Errors?

.NET does have the Exception Handling Application Block and it looks very promising, although it also looks very involved. And do you really want to be able to configure exception handling policies via config files? I mean, beyond indicating the level of logging you want (verbose, medium, low, off), and the email address to send exception report to (unluckysupporttech@mycompany.com), I'm having a hard time coming up with anything else I've ever needed to dynamically configure in my apps for exception handling. But, I won't say it couldn't be useful.

In the end, I suppose the thing that bothers me most about the EHAB, and the whole structured exception movement in general, is that it really does nothing to address the Unexpected Errors in an application. You still have to wrap your entire procedure in a TRY block in order to be sure that you catch any exception raised in that procedure. Otherwise, the exception is simply propagated up the call stack to the first point that is covered by an exception handler. The good news about .NET, though, is that at least, in those cases, you can still retrieve a call stack back to the real source of the exception and log it. With VB6, no such luck without some sort of framework.

My other issue is that Try Catch style exception handling forces the declaration of how you intend on handling errors to the END of the function you're looking at. In this age of declarative programming and metadata-attributed interfaces, that just seems so...yesterday.

Take my above comparison of try catch and on error. What actually happens to the error is stated down at the end of the procedure in both styles. Now. I can understand that approach if you have code dedicated to handling specific errors, but then, those are Expected Errors. For the Unexpected Errors, I'd rather know, declared right up front, how the prodecure intends to handle them.

That was the impetus of my article way back when:

• Provide a framework that could provide a call stack that VB6 was lacking
• Provide a means of clearly declaring how the procedure intends on handling Unexpected Errors.

Compare a typical Try Catch structure:

Public Sub Test()
   Try                                          
   .....Lots and lots and lots of code....
   Catch Ex as Exception
   ....how to handle specific exceptions, plus how to handle general exceptions...
   End Try
End Sub

with a prologue style declaration like I use in my error handling framework for VB6:

Public Sub Test()
'############### ERR HANDLING #############
Dim Err As CErr: Set Err = New CErr: On Error GoTo Problem
Problem:
Select Case Err.Handle(EHF_PRESENT or EHF_ALLOWRETRY, MODULE, "Test")
Case EHE_NONE: Case EHE_RETRY: Resume: Case EHE_PASS: Resume Next: Case EHE_RESET: Resume Problem
End Select
'##########################################
   .....Lots and lots and lots of code....
End Sub

The code states right up front how unexpected errors are handled (in this case, EHF_PRESENT or EHF_ALLOWRETRY indicates that the user will be shown a dialog and allowed to retry the operation). There's a bit more verbiage here because of the requirements of VB6, but that's not the point.

Personally, I'd prefer it if every routine in .NET could be (or maybe even had to be) attributed as to how unexpected errors are to be handled. Those that need to show a dialog would do so based on one or more "predefined" dialogs that depended on where in the app the error was thrown.

And for those apps that you never want to show an error dialog, you could instead indicated that any unexpected errors should be logged to the Event Log (or somewhere else) and then press on as best as possible.

Unlike the implications in so many magazine articles, error handling is hard. Proper error handling is like a prostate exam; you know you have to do it, but you'd really rather not bother.

In case you've missed the first 2 posts in this series, I'm discussing the concept of using Resouce files with Visual Basic 6.

In the first part, I talked about how to compile arbitrary information into a resource file and reference it from VB.

In Part 2, I discussed a technique for compiling a VersionInfo resource and writing it into your VB executable, thus replacing the incomplete VB provided VersionInfo resource.

In this installment, I wanted to share a little trick for defining the elements of the "Version number" in a resource (RC) file such that you only have to enter the version number once.

If you recall, I presented a sample RC file the last time, looking like this:

1 VERSIONINFO
FILEVERSION 1,2,3,4
PRODUCTVERSION 1,2,3,4
FILEOS 0x4
FILETYPE 0x1 //// 2 for dll, 1 for exe
{
BLOCK "StringFileInfo"
{
BLOCK "000004b0"
{
VALUE "CompanyName", "MyCompany"
VALUE "ProductName", "MyProduct"
VALUE "FileDescription", "MyFileDesc"
VALUE "LegalCopyright", "MyLegalCopyright"
VALUE "LegalTrademarks", "MyLegalTrademark"
VALUE "OriginalFilename", "MyOriginalFilename"
VALUE "ProductVersion", "1.2.3.4"
VALUE "FileVersion", "1.2.3.4"
VALUE "Comments", "MyComments"
VALUE "InternalName", "MyInternalName"
}
}
BLOCK "VarFileInfo"
{
VALUE "Translation", 0x0000 0x04B0
}
}

If you'll notice, there is one thing about this script that no lazy programmer worth a macro recorder would tolerate. The Version Number is duplicated several times, and what's worse, in several different formats.

First, we have the FILEVERSION and PRODUCTVERSION entries, with comma separated numbers.

But then we also have the stringized version of those two elements, that must be specified as period separated elements within quotes.

I don't have an alcohol fueled Code Sync 5000 robot to keep those numbers straight so I figured I'd just use macro substitution. Right. Turns out, the Resource compiler (RC.EXE) is a mighty fickel beast.

What I envisioned was a simple block to define the version number:

#define MAJOR          1
#define MINOR          0
#define REVISION       0
#define BUILD          116

and then use those definitions further down in the file, like so

FILEVERSION MAJOR,MINOR,REVISION,BUILD

and similiarly

VALUE "ProductVersion", "MAJOR.MINOR.REVISION.BUILD"

But obviously, there's a problem; actually, more than just one.

I won't dwell on the details, but after much head scratching (polite euphimism), I ended up with this joyous concoction:

#define COMMAVER(mj,mn,rv,bl)        mj,##mn,##rv,##bl
// Commaver yields x,y,z,a  (necessary for the numeric versions)

#define PERIODVERPT2( mj )           #mj ""
#define PERIODVERPT3( mj,mn,rv,bl )  PERIODVERPT2( mj ) "." PERIODVERPT2( mn ) "." PERIODVERPT2( rv ) "." PERIODVERPT2( bl )
#define PERIODVER                    PERIODVERPT3( MAJOR,MINOR,REVISION,BUILD )
// PeriodVer yields x.y.z.a (necessary for the stringized versions)

// define the two numeric versions
// always make them the same                    
#define FILEVER        COMMAVER(MAJOR,MINOR,REVISION,BUILD)
#define PRODUCTVER     FILEVER

// define the two stringized version numbers, we just make them the same
#define STRFILEVER     PERIODVER
#define STRPRODUCTVER  PERIODVER

Then you can use them like so

....
FILEVERSION FILEVER
PRODUCTVERSION PRODUCTVER
....
VALUE "ProductVersion", STRPRODUCTVER
VALUE "FileVersion", STRFILEVER

Get clever with the #include directive and you can easily keep the version numbers of all the separately compiled VB components of your project synchronized and only have to set the version number in a single place.

If there's a simpler way, I'd love to hear about it. But this works, and it keeps all my version numbers straight.

I've seen lots of rants over the years saying things along the lines of

Who wants to use a language that looks like this:

10   Print "Hello, World"
20   If x = 1 Then Goto 50
30   Print "Something else"
50   Print "Result was 50"

Or similiar nonsense. Of course, VB only vaguely resembles this style of code anymore, but one thing has remained virtually the same. Line numbers.

If I remember correctly, in BASCOM and BASICA, they were required. Then Basic Professional Developer System (MS BasicPDS) came out and line nums were no longer necessary, but you could still use them if you liked (probably more to be backwardly compatible with all that old BASICA code).

In all the older VBs (pre .NET days), you actually had to add line numbers to the source code itself in order to get them into the program and refer to them (via the ERL function). While this was certainly doable, the resultant code ended up looking like some seriously old-school mash you wouldn't want to be caught dead delivering (or trying to maintain).

However, being able to report a line number during an error at runtime, at the client site, so it can be logged or reported back to you as a developer is damn near invaluable. Microsoft recognized this enough in .NET to include line number support built in to the error stack and handling subsystem (although the old style line numbers in code and ERL function still work, appearently).

That's great for .NET, but there's still a lot of VB6/5 and older code laying around that has to be maintained. So what do you do?

Ages ago, I built a little command line utility to run through every module in a VBP file (and every module of every project in a VBG file, too), and either add or remove line numbers. It output all the files to the same directory, but with "LINED_" prepended to the file name. This tactic makes it very easy to simply DEL LINED_*.* when you've compiled the line numbered project to clean things up and not leave line numbered code sitting around. You can run it against individual BAS, FRM, CTL, DSR, CLS, etc files, but if you point it at a VBP or a VBG file, it'll even rewrite that file so that it's contents point to the new file names. This makes it very easy to construct a batch file to 1) line number a project, 2) compile it, and 3) kill off the line numbered source files.

For instance, this batch file:

set pfile=%~dpn0
set pname=%~n0
set pdir=%~dp0
vbliner %pfile%.vbp
VB6.EXE /m "%pdir%LINED_%pname%.vbp"
del "%pdir%LINED_*.*"

Just name it the same name as a VBP file, save it to the same folder as your VBP file, and run it.

It will pull the file name and path from the name of the batch file itself (which should be the same as the VBP you want to compile), line number the project, compile it, then delete the line numbered source files when fnished, leaving you with a nice compiled file, completely line numbered but with none of the mess.

Its other nifty trick is to line number the lines using the same algorithm that the VB6 IDE uses to display line numbers as you move through code, as in:

This one trick (which I haven't seen in any utility to line number VB source), makes it so that you don't have to keep the line numbered source around so you can refer to it later. Somebody calls up saying they get an error in Module XYZ, line number 10202, all you have to do is pull that version of the module from SourceSafe (you do use version control of some kind, right?), load it up in VB and jump to the given line number. Can't get much simpler.

VBLiner starts numbering at 10000, the rational behind that being that if you happen to need to include a hardcoded line number in your code for some reason, the automatic numbers hopefully won't interfer with your hand coded numbers.

Another handy tip. Once you've opened your VB project, Right click the project explorer, select ADD, then ADD FILE. Find the BAT file that you just created above, and be sure and check the "Add as Related Document" box before adding it to your project. Now, then, you should be able to simply DBL CLICK on the BAT file from the VB project explorer to run the bat file and compile your project, complete with line numbers, all automatically.

And a final note; VBLiner does ostensibly support removing line numbers from VB files as well, but I've never had much use for that facility, so it's not well tested. As with any freeware, use at your own risk. And it should go without saying, Back up your source files before running it on them.

Download a zip of the utility here and let me know what you think.

VB has one of the best IDE's around. Sure Eclipse is pretty capable, Delphi is quite slick, and for the purists, editors like SlickEdit can make you almost believe you're coding in an IDE.

But VB's IDE is the one to beat. And it has been since VB3.

But even the best have issues; mistakes, ommisions, things that jsut could have been so much better.

And that's where MZTools comes in.

If you haven't already played with it, download a copy and install it now. Carlos originally built MZTools for VB6 way back when, and that version was (and still is) a free utility. He's branched out to supporting Visual Studio .NET now, and the newest version is not free, but it is worth every penny.

Take a look at the features page for version 3 (which supports VB6). The Code Review, Code Templates, and Error Handler Templates are gauranteed to save tons of time.

Personally, I don't like his line numbering support. I feel like the line number applied to a line should be the same as the actual line number in the file, as reported by the VB6 editor, like this:

That way, you don't have to retain the numbered version of the source to be able to refer back to a specific line number. However, this is a pretty minor nitpick.

In short, MZTools is a massively handy utility to have on you're VB menu bar. Definitely for VB6 (cause it's, well, free), and worthy of consideration for .NET.

By now, I suspect the Office 2007 Ribbon is a bit old news.

From a developer's point of view, it's relatively easy to customize the ribbon via add-in code, which is really nice. And since there seems to be no dearth of examples on doing so, I won't be wandering down that path.

For Word, Excel, and PowerPoint, things are pretty straightforward, because, as far as I can tell, there's only one Ribbon for them.

But in Outlook, things are more complicated. The main Outlook window doesn't even have a ribbon. But the sole parameter of the main entry callback for customizing the ribbon is:

Public function GetCustomUI(ByVal RibbonID as string) as string

so what are the possible RibbonIDs?

After a good bit of searching, I found the following table in the VSTO3CTPTutorial.doc file that identifies them all:

BTW, for those that are interested, in Word, the RibbonID is always Microsoft.Word.Document

Similiarly, in Excel, it's Microsoft.Excel.Workbook

and in PowerPoint, it's Microsoft.PowerPoint.Presentation

I wasn't able to find that info published anywhere. I suppose it's technically irrelevant, but still...

It's tough to write well. Unfortunately, too many people out there don't realize this.

I realize it. I also realize I don't write particularly well, but recognizing your problem is always the first step, right?

I just came across a Gar's Tips on Sucks-Less Writing that lays down 10 rules to tighten up your writing. It's old news, sure, but there's good stuff there.

In the end, I suppose the most important concept to osmose is to say enough, and nothing more.

I've played a bit now with the .NET configuration model and while I can certainly see some elements in there to like, it seems to me that it falls short in a number of different ways.

First off, it doesn't really have any concept of "multi-level configuration." In fact, it's basically a single level XML file (granted, you could create a hierarchical organization within that single xml file, but there's other issues with that). .NET does help a bit with the concept of a machine config file, but from what I can tell that's about as far as it goes.

Second, the default behavior is to locate the application config file in the same path as the application itself. That's great if your user is running as administrator, but not so great in more locked-down situations where users do not have full admin rights. In those cases, configuration that's writable needs to be stored somewhere within the user's profile directory structure. This is just going to get worse with Vista, too.

Ok, sounds good but what, you may be asking, is a multi-level configuration scheme, and why would I want one? Almost every app I've ever worked on, short of the trivial utilities I've built, has required this sort of configuration scheme (or at the very least greatly benefited from having it). It almost always follows along this line:

• Administrator specified User specific configuration (rarely used, the user cannot change this configuration)
• User specific configuration (that the user can change dynamically)
• Group specific configuration (typically set by a system administrator or group admin and read only to users)
• Machine specific configuration (typically set by a system admin, and rarely used, read only to users)
• Application global configuration (typically set by the system admin, read only to users)
• OEM defaults (typically set by the app developers to provide default config values, generally readonly by everyone except the developers)

At each level, the system provides for an essentially unlimited number of name value pairs that can be cordoned off into groups (or sections as they used to be called in INI files). Some may argue that a section-name-value system like this is too limiting and you should always accomodate full hierarchical structures, but I've found the extra functionality rarely necessary.

Of course, the type of value (string, int, date, etc) for a particular setting is defined within the application, but value types might also be defined as OEM default settings. Should sysadmins really be able to change setting X from a string to a date? I'd imagine not usually.

The trick and the real beauty of the system is in the way that setting values are resolved. The resolution logic basically says that if the app can find a setting at a higher level in the hierarchy, it uses that value. Otherwise it searches down the hierarchy till it either finds a value, or till it drops to the OEM defaults. If no setting is specified at the OEM level, the system defaults to blanks, or 0's depending on the data type.

So, for instance, the code might ask for the setting "AskOnExit" from the "Prompts" section. The config handler needs to look first at the "level of most significance" which, in the above list of levels, would be the Administrator specified user specific settings (ie those settings that are set on a per user basis, but that the user himself doesn't have the authority to change.

If the setting isn't found there, the code continues down the hierarchy, looking at each level in turn until eventually in run through them all and returns the default or a blank or 0.

And, of course, you also have to provide a means to retrieving and writing a setting at a specific level in the hierarchy, for those settings that are always application level or machine level or what not.

Obviously, such a scheme requires a little more work up front, but the configuration flexibility (especially when you're talking about major, multi user systems with lots of configuration options, typically off-the-shelf, reseller-friendly applications like accounting systems or CRM packages), is a huge selling point to admins and users alike.

Why, then does configuration handling in .NET seem so archaically primitive?

Could you roll all these levels into that singular .config file? Sure, when where would you put it? In the Application path? No, users won't typically have write rights there. Under the user's Application Data folder in the Profile? No, can't put app wide settings somewhere that only a single user can access it. How about that machine config file. Again, not writable by typical users.

It's funny that Windows already has a rights system that is very stable, quite flexible and easy to work with, both manually and from within code and yet it often goes completely unused by larger apps. I'm talking, of course, of the file system.

These days, though, web apps are de rigueur and you can't go assigning file system rights to web users. There's no way that would fly with most web developers (you weren't really thinking of something like that, right?). So, roll it up into a simple table, with a getSetting and a setSetting stored procedure to simplify the coding. With proper indexing, and a little intelligent caching, it'll be every big as fast as using the .NET configuration functions, and whole lot more flexible.

Long story short. If your sideline utility needs to save a few settings, use the .NET configuration. It's fast, relatively easy and convenient. But for just about everything else, take a little time and do it right.

Your users and their sysadmins will thank you.

If you've ever looking closely at Windows applications, you know that Windows Version Numbers are composed of 4 parts:

• Major version
• Minor version number
• Revision number
• Build number

So a version of 4.8.3.9888 would typically mean Major version 4, Minor version 8, Revision 3, Build 9888.

If you've ever looked at VB's Project properties box, though, you've probably noticed the disconnect.

Obviously, VB directly supports the Major and Minor, and appearently, the Revision number.

But, build a VB6 app with unique values in for each number and then view the app's properties via Windows Explorer:

In this particular app's case, Major and Minor are 0, and Revision was set to 49. However, according to the Windows Property panel, the Build number is 49. VB internally makes the Build number what you enter as the Revision number in the VB project property UI.

Now, whether this was just a typo on the part of the VB developers or an intentional "feature", I can't say. But it definitely can cause confusion and make it difficult to identify versions of your app out in the field. Then there's the constant explaining of why your app's revision always seems to be 0, but other applications have something there.

In a previous post on VB and resources, I mention the Microsoft Resource Compiler, a utility that can compile resource files into RES files, which can then be compiled into your application by VB.

This combination works wonders if all you want to do is embed icons, bitmaps, strings or arbitrary files into the resources of your app.

And, if you look at the RC documentation, you'd see info on VERSIONINFO statement that is used to define a Version Info Resource.

So, it would stand to reason that if you created a resource file, say like this:

VersionInfoTest.rc

1 VERSIONINFO
FILEVERSION 1,2,3,4
PRODUCTVERSION 1,2,3,4
FILEOS 0x4
FILETYPE 0x1 //// 2 for dll, 1 for exe
{
BLOCK "StringFileInfo"
{
BLOCK "000004b0"
{
VALUE "CompanyName", "MyCompany"
VALUE "ProductName", "MyProduct"
VALUE "FileDescription", "MyFileDesc"
VALUE "LegalCopyright", "MyLegalCopyright"
VALUE "LegalTrademarks", "MyLegalTrademark"
VALUE "OriginalFilename", "MyOriginalFilename"
VALUE "ProductVersion", "1.2.3.4"
VALUE "FileVersion", "1.2.3.4"
VALUE "Comments", "MyComments"
VALUE "InternalName", "MyInternalName"
}
}
BLOCK "VarFileInfo"
{
VALUE "Translation", 0x0000 0x04B0
}
}

Then, all you should have to do is compile the RC file with RC.EXE, load up VB, add the resulting RES file to your project and you'd be done.

Unfortunately, the path to enlightnment is never straightforward, and neither is the process of getting a proper version number into a VB6 executable.

The problem is that VB post-processes the compiled executable in order to put the version information from the Project properties screen into the VERSIONINFO resource. This means that the nice, correct VERSIONINFO resource that you just compiled into the executable get's stomped on by whatever you happen to have in the Project Properties dialog, and that dialog will always reset the Windows Revision number to 0, and use the VB Revision number as the Windows Build number.

What you have to do is post-post-process your exe and put the correct VERSIONINFO resource back in after VB is completely finished with the file.

And the easiest way to do that is with a handy free utility called Resource Hacker. This utility allows you to easily open, view, and even extract all the resources in any EXE or DLL. If you want to just pull all the icons out of a file's resources, there are definitely better ways. But if you really want to poke around the resources in a file, ResHacker is perfect. Plus, it's got a very handy, if not a little arcane, command line interface that will allow you to automate much of the process via MAKE files or batch scripts.

Make sure the RESHACKER.EXE is on your path, then run:

reshacker -addoverwrite "yourexe.exe", "yourexe.exe", "yourexe-VersionInfo.res", versioninfo, 1 , 1033

I'm assuming your compiled application is called yourexe.exe, and that you've compiled an RC file with a VERSIONINFO resource in it to the file yourexe-VersionInfo.res.

Resource hacker will dutifully wipe out the VB created VERSIONINFO resource and replace it with the one compiled from your RC script.

One important note, though. ResHacker will not merge a single resource, and all of the version information is considered a single resource. That means that you need to specify all the pertinent version info properties in your RC file, because everything specified via the VB Project Properties dialog will get replaced.

"But", you say, "the version numbers themselves appear to be replicated 4 times in the RC file! I'm a lazy programmer and the thought of updating 4 copies of the version number just seems, well, wrong."

And you'd be right.

Fortunately, there is a way to convince RC.EXE to allow you to specify the version number for your app only once. However, doing so is, like the concept of using resources in a VB app, more complicated that you would at first imagine.

I'll discuss that in my next post.

Feng Shui is all about the placement of things to better harmonize with their (and consequently your) surroundings.

With VB, there's no better place to examine that than the file footprint of your application.

Ask yourself: You have two apps to evaluate. They perform identically, are configurable in all the same ways and behave exactly the same. One app consists of hundreds of files scattered across dozens of folders. The other's footprint is exactly one file, the EXE itself. Which would you choose?

Granted, that's an extreme case, but the point is, the smaller your app footprint, the better, in almost all circumstances.

And a really nice way to shrink an app footprint is with resources.

If you've never messed around with resource files in VB6, or maybe only tried to use the built in resource editor add-in, you really don't know what you're missing.

Resources can be an immensely handy way to embed everything from pictures to WAV files, to chunks of script, to icons, and just about anything else directly into your application, but in a way that makes them accessible to the outside world, for one-off customizations, translations, or to just keep the file footprint of your app as small as possible.

However, resource files can be notoriously difficult to work with because of the lack of tools available natively with VB6. VB.NET dramatically improves upon the situation, but there's still a lot of VB6 code out there that might benefit from resources.

Generally speaking, you have two "types" of resource files where VB6 is concerned.

• the resource file the can be "included" in the project and is available to your code while you're running in the IDE
• Any resources "added" to your applications EXE/DLL/OCX file AFTER you compile it.

Why the distinction?

There's one specific kind of resource that you very much should want to include in your compiled file, but which VB is notoriously lacking about. The Version Info Resource.

VB only allows you to specify the Major, Minor, and Build version numbers (although VB calls the Build number, the "revision" number, mysteriously).
Windows executables, on the other hand, support a Major, Minor, Revision, and Build.

Now, the truth is, VBs support is generally fine for utilities, hobbiest programs and the like. But real, commercial applications really should make use of all four numbers, and that's something that is impossible using VB alone.

Ah, you say, VB does have that "Resource Editor" add-in, just use it! Not quite. You can't create a version info resource in it, and even if you could, VB's compiler replaces any version info element within that resource file with the information from the project properties window.

The solution is relatively simple and still preserves all the great things that resource files in VB can do for you.

The IN-THE-IDE Resource file

For this resource file, you have 2 choices, use the VB Resource Editor Add-In, or create an RC resource script file, and compile it to a RES binary format file that VB expects. I prefer the later, simply because scripting the resource file makes it much easier to include things like big chunks of text (xml, scripts, icons, what-have-you), and you can leave all of those things external to the RES file without having to manually pull them in via the Editor add-in every time they change.

I usually create an RC file with the same name as the VBP file, but with an RC extension

test.RC

// Test Resource Compiler file
// used to automatically compile the RC file into a RES file
// BEFORE the project itself is compiled
// This makes the Resource data available to code while in the IDE
//
//-----------------------------------------------------------------------------------
// Arbitrary Text File Resources
//
//----------------------------------------------------------------------
TEXTRES1   TEXTRES_DEFS PRELOAD DISCARDABLE TextRes1.txt
TEXTRES2  TEXTRES_DEFS PRELOAD DISCARDABLE TextRes2.txt

//-----------------------------------------------------------------------------------
// Bitmap Resources
//-----------------------------------------------------------------------------------
IMG_MAIN  BITMAP PRELOAD  DISCARDABLE ".\test.bmp"

Note that test.bmp is just some random bitmap file, and that TextRes1.txt and TextRes2.txt are arbitrary text files.

Then, you can access those resources via a little bit of VB code

To get the text file resources

Dim a() As Byte
dim buf$
a() = LoadResData("TEXTRES1", "TEXTRES_DEFS")
buf$ = StrConv(a, vbUnicode) 'need to convert the raw ansi text file content to UNICODE to make VB happy

Or to load the bitmap

Set form.Picture = LoadResPicture("IMG_MAIN", vbResBitmap)

Icons, and string tables are a little more difficult, esp. with respect to XP and VISTA format icons, so I'll worry about them later.

You can compile the RC file using a command line similiar to the following:

rc.exe /r /fo "test.res" "test.rc"

Make sure the RC.EXE resource compiler is on your path for it to run right. The RC.EXE file itself should be somewhere in the VB6 installation folder under Program Files. For a muhc more thorough explanation of the Resource Compiler, check here. Microsoft has some very good RC information here also.

Alternatively, you can put this command in a BAT file, and execute it quietly:

cmd /Q /c rc.ex /r /fo "test.res" "test.rc"

One caveat. If you decide to use the RC file, be aware that VB loads the compiled RES file when you load the project. So if you make a change to one of the component resource files (say, an ICO or BMP file), you'll need to exit VB, recompile the RC file to a RES file, and then RELOAD the project in VB. Since RES files don't change all that much once initially created, this isn't a huge problem.

Another note: You can only include one resource file in a single VBP project, so it has to contain all the resources the app will need (except, of course, for the Version Info Resource).

And a final note: You can easily add a resource file to a project by
1) compiling the RC file to a RES file
2) Opening your VBP project
3) dragging the RES file from Explorer to the VB Project Window.

For next time, handling the Version Info Resource....

Why is it that VB (and VBScript) seems to be more prone to poor code styling than most other languages.

I suppose it's likely because Basic is, if I recall correctly, the most widely used language out there. And if something's that widespread, well, bad things are just bound to happen, and happen more often.

I was looking at some code recently (I read lots of code) and saw this (the function name and a few comments have been removed but otherwise this is exactly as I found it, and I'm not even concerned with what the code does for this purpose):

Function XXXX(Optional AutoRestart As Bo olean = True, Optional CreateNew As Boolean) As Boolean
InitCommonControls
On Error Resume Next
Dim XML             As String
Dim ManifestCheck   As String
Dim strManifest     As String
Dim FreeFileNo      As Integer

If cIDECheck = True Then AutoRestart = False
If AutoRestart = True Then CreateNew = False

XML = (" " & vbCrLf & "<assembly>" & vbCrLf & "<assemblyidentity>" & vbCrLf & "    <description>EXEDESCRIBTION</description>" & vbCrLf & "    <dependency>" & vbCrLf & "    <dependentassembly>" & vbCrLf & "    <assemblyidentity>" & vbCrLf & "    </dependentassembly>" & vbCrLf & "    </dependency>" & vbCrLf & "</assembly>" & vbCrLf & "")

strManifest = App.Path & "\" & App.EXEName & ".exe.manifest"    'set the name of the manifest
ManifestCheck = Dir(strManifest, vbNormal + vbSystem + vbHidden + vbReadOnly + vbArchive) 'check the app manifest file.
If ManifestCheck = "" Or CreateNew = True Then           'if not found.. make a new one
XML = Replace(XML, "EXENAME", App.EXEName & ".exe")             'Replaces the string "EXENAME" with the program's exe file name.
XML = Replace(XML, "EXEVERSION", App.Major & "." & App.Minor & "." & App.Revision & ".0") 'Replaces the "EXEVERSION" string.
XML = Replace(XML, "EXEDESCRIBTION", App.FileDescription)       'Replaces the app Describtion.
FreeFileNo = FreeFile      
If ManifestCheck <> "" Then
SetAttr strManifest, vbNormal
Kill strManifest
End If
Open strManifest For Binary As #(FreeFileNo) 'open the file
Put #(FreeFileNo), , XML    'uses 'put' to set the file content.. note that 'put' (binary mode) is much faster than 'print'(output mode)
Close #(FreeFileNo)         'close the file.
SetAttr strManifest, vbHidden + vbSystem
If ManifestCheck = "" Then
XXXX = False            
Else
XXXX = True
End If
If AutoRestart = True Then  
Shell App.Path & "\" & App.EXEName & ".exe " & Command$, vbNormalFocus  'restart the program and bypass command line parameters (if any)
End                         
End If
Else                'the manifest file exists.
XXXX = True      'return true.
End If
End Function

Now, I'm sure this code functions just fine and is probably quite useful, but how can even the guy that wrote this come back and read it, quickly, 6 months from now?

I indented the same code and took screen shots to compare them side by side (the highlighter is mine):

Note how the highlighter (and your eye) is naturally drawn into the curves of the indentation.

By comparison, the unindented code yields a straight line. There are no clues to tell your eyes where to look.

A guiding principle in feng shui is that straight lines are generally bad. Many books on the subject call them poison arrows because, it's believed, straight lines tend to direct negative chi (energy) toward whatever they're pointing at.

In the same way that you generally do not want an arrow straight walkway directly from the street to your front door, you do not want an arrow straight eyeball walkway that directs the eye right by the code it's supposed to be reading.

Long story short, it's good to be a lazy programmer, but it's certainly possible to be too lazy.

Visual Basic's got a bit of a bad rap as it is. A little less of this might go a long way towards helping that.