Visual Studio Magazine

Classic VB Corner

Customizing the Ride Part 2

Karl Peterson returns with another batch of tricks designed to improve the IDE.

• By Karl E. Peterson
• 04/12/2010

Does it bother anyone else that enumerations don't hold their case, like normal variables and constants do? That is, if you declare a module level variable:

Private aRidicuLousCamel As Whatever

And then later on in some routine elsewhere, you just merrily typing away, and enter the variable name in all lowercase, VB will automagically correct the case for you to match the declaration. I'll bet a great number of you rely on this feature to be sure you've spelled the name of the variable correctly?

But if you were to declare an Enum in the same manner:

Public Enum LocaleDateFlags
   DATE_SHORTDATE = &H1
   DATE_LONGDATE = &H2
End Enum

Now, if you were to type "date_shortdate" in your procedure window, you'll perhaps be surprised to see that it doesn't change to all caps as it was declared. Well, that's the way Classic VB is, and there's nothing we can do to change that. But we can force the case fairly easily.

The trick is to declare the variables again, but in a segment of code that doesn't actually even get compiled. I do it like this:

#If False Then
   ' Placing these constants within a conditional compiler block
   ' forces the IDE to propercase them whenever typing anywhere
   ' within the project.
   Private Sub ForceEnumCase()
      ' Date Flags for GetDateFormatW.
      Const DATE_SHORTDATE As Long = &H1
      Const DATE_LONGDATE As Long = &H2
   End Sub
#End If

Now, when I type "date_shortdate" and hit return, the IDE automagically capitalizes it just as it should. Yeah, it's a little extra setup, but it can truly save considerable frustration down the road.

Testing for Out-of-Range Enums
This is one I have to search high and low for, every time I need it, because no matter what I always forget it! I frequently write routines with arguments that are of an enumerated type. This makes providing the arguments while writing code as simple as could possibly be, because as I'm typing away I get a nice drop-down list of potential argument values from Intellisense. But how do I test to see whether an argument is in range, within the called procedure?

Let's use the following Enum, from my Uptime sample, as an example. The ProcessTimes enumeration consists of four sequential constants:

Public Enum ProcessTimes
   piCreationTime = 0
   piExitTime = 1
   piKernelTime = 2
   piUserTime = 3
End Enum

You can then write a routine that expects one of these values, by simply declaring the argument As that type:

Public Property Get ProcessTime( _
   ByVal WhichTime As ProcessTimes) As Date

When coding, Intellisense will provide you with the dropdown list of options. But you aren't forced to use any of them, of course, and there may be times when you want to use a calculated value anyway. Perhaps an error would be triggered in the called routine, if you passed an out of range value, though. You could do tests like this:

If WhichTime >= piCreationTime And _
   WhichTime <= piUserTime Then

But how ugly is that??? Imagine if you need to rename a constant or expand or reorder the list or any number of other things that could muck that up. How many places might you have to remember to update that test? Here's a solution that only requires a single tweak if your Enum changes. Declare it like this:

Public Enum ProcessTimes
   [_ProcessTimesMin] = 0
   piCreationTime = 0
   piExitTime = 1
   piKernelTime = 2
   piUserTime = 3
   [_ProcessTimesMax] = 3
End Enum

The underscore used in the first and last constants is an invalid leading character, of course. But putting the brackets around it tells VB to allow it in this specific case. It's useful in two very special ways. The bracket-underscore combination 1) will not show up in Intellisense, and 2) can be used in code!

This means you won't see those values when Intellisense pops while you're writing code, but you can still test for them in the code you're calling. The awkward test above becomes:

If WhichTime >= [_ProcessTimesMin] And _
   WhichTime <= [_ProcessTimesMax] Then

Never again needing to be updated, should your Enum change.

Reader Comments: