Figure 1 Uncover Hidden Resources. Click here.

Begin the actual enumeration with a call to EnumResourceTypes, passing it the hModule retrieved by LoadLibraryEx and the address of a callback procedure. Optionally, the third EnumResourceTypes parameter accepts a Long, which is later passed directly to the callback. You can use it to indicate how the callback should process other incoming data.

The function prototypes for your callback procedures are defined precisely. EnumResTypeProc expects to receive three Longs—a handle to the module being enumerated, a pointer to a string that describes the resource type, and the optional value that you might have passed as the last parameter to EnumResourceTypes. Of these, the most interesting is the resource description.

About 20 resource types are predefined, but developers are free to define their own as well. If the current resource is one of the standard types, lpszType contains a value that maps to one of the RT_* constants that now range from 1 to 23. More standard types will be added as time goes on, no doubt. But if the current resource is user-defined, not standard, then lpszType is a pointer to a resource type's string description.

How can you tell what the callback passed? If the hiword of lpszType is zero, the loword contains a numeric ID. If the hiword isn't zero, it passed a pointer, and you need to dereference it into a standard VB string variable (see Listing 2). In either case, simply enumerating all resources of this type requires that you pass hModule and lpszType directly to EnumResourceNames, along with the address of your desired callback routine and an optional Long user data value.

As before, you must define EnumResNameProc precisely. The parameters are similar to EnumResTypeProc, with one addition that provides the resource ID. Decode both lpszType and lpszName, as before. If the hiword is zero, you have a numeric ID; otherwise, you need to dereference a string pointer.

Q. Implement Callbacks in Classes and Forms
Windows offers all kinds of cool callbacks, which have been accessible since VB5's introduction of the AddressOf operator. But it bothers me to no end that I can direct these callbacks only into standard BAS modules, instead of where I'd really like to send them—into my classes and forms. This seems to go against all the principles of encapsulation I strive for. How can I reroute these callbacks to where they're really needed?

A. I agree: AddressOf's limitations are frustrating, but they're not insurmountable. My own preference is to define a custom callback interface. Forms and classes can use Implements to offer this interface to the system callback procedures. This means you're now stuck with two extra modules instead of just one, but it also means you can move callback processing back to where it really belongs.

Let's use the above resource enumeration as an example. First, define your interface class, IEnumResources:

Option Explicit 
Public Sub EnumResourceSink(ByVal _
   ResName As String, ByVal ResType _
   As String, Continue As Boolean)
   ' This routine is called by 
   ' the MEnumResources module
   ' once for each resource type 
   ' found and once for each
   ' named resource of that type.
   '
   ' Allows enumeration to be handled 
   ' in class or form modules.  
   ' Enumeration continues until all 
   ' resources have been found or 
   ' Continue is set to False.
End Sub

Open the code window to your class or form module and add this to the Declarations section:

Implements IEnumResources

Now drop the Objects box, which displays the names of all objects associated with the module, and select IEnumResources. This interface includes only one method, so the EnumResourceSink prototype is added to your code window immediately:

Private Sub IEnumResources_EnumResourceSink _
   (ByVal hModule As Long, ByVal _
   ResName As String, ByVal ResType _
   As String, Continue As Boolean)

End Sub

Next, expand on the EnumResources function in Listing 1, adding a new function that supports an additional argument—a pointer to your implemented interface:

' Reference to callback interface
Private m_Callback As IEnumResources

Public Function _
   EnumResourcesEx(Callback As _
   IEnumResources, Optional ByVal _
   ModuleName As String = "") As Boolean
   ' This routine is *not* re-entrant!
   If m_Callback Is Nothing Then
      Set m_Callback = Callback
         EnumResourcesEx = EnumResources(ModuleName)
      Set m_Callback = Nothing
   End If
End Function

Call EnumResourcesEx, passing Me as a pointer to your implemented interface:

Call EnumResourcesEx(Me, FileSpec)

The last step is to add support for interface notification to your callback routines. For example, EnumResNameProc tests whether the module-level m_Callback object variable has been set to point to an IEnumResources interface. If so, EnumResNameProc notifies that interface each time it's called by the system (see Listing 3).

This probably seems like a tortuous path simply to maintain some semblance of encapsulation; however, it's worthwhile because you now have the full decision and action power back where it belongs.