personal info | online resume | project details | vb downloads | contact
Page Links
  • Windows Knows
  • But How?
  • Other Ideas
  • Take It From Here

  •  Article Index
    And Now, For Something a Little Different
    Windows Knows
    This week, we're going to try something a little different. We're going to look at a way you can save yourself some time working with the files that we VBers typically work with every day.

    As an example, let's think about text files, those plain old text documents with the txt extension. Open up Windows Explorer and find a text file in folder somewhere. Right click the file and examine the upper part of the context menu that appears. Depending on what's installed on your system, you'll probably see things like Open, Print, etc.. The items that appear in the menu are the things that Windows knows how to do with the type of file you right-clicked on.

    But How?
    The first thing we're going to do is understand just how Windows knows about this type of file and what exactly Windows will do with the file, based on which menu item you click. Open up your registry editor. If you haven't opened it before, just click on the Start button and click Run.... In the Run dialog, type regedit and press Enter. This will open up the Windows Registry editor. For those of you who've been here before, bear with those who haven't. What you'll see in the left portion of the Registry Editor window are called registry hives. You may see four, five, six, or more hives. They have names like HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, etc.. Next to each hive, you can click on the + sign just like in Windows Explorer to expand that hive. The values appearing under each hive are called subkeys. Sometimes, you'll see only a few subkeys under a hive. Sometimes, you'll see hundreds. Let's expand the first hive, HKEY_CLASSES_ROOT. The first subkeys you'll see look like file extensions. Scroll down this list until you get to the .txt subkey and click on it. If you don't feel like scrolling through the list, select the first subkeys and type .txt rapidly. The Registry Editor will watch the keys as you type them and zoom you down the list quickly to the entry that matches what you type. Either way, once you've located the .txt subkey, click on it. In the right-hand window of the Registry Editor, you'll see at least one item, possibly two. The one you will definitely see is called (Default). The items appearing on this side of the Editor are called values. Each value has a name and, well, a value. The (Default) value probably has a value of something like "txtfile". Let's use this value to continue our search. Click on the .txt subkey again (just in case you clicked somewhere else) and type txtf quickly. Again, depending on what is installed on your system, the Registry Editor will probably jump you quickly down to a subkey called txtfile. The name of this subkey matches the value of the (Default) value for .txt. This subkey is used by the Windows shell to provide additional information about files ending with .txt. If you expand the txtfile subkey, you'll see a lower-level subkey called shell. Sound familiar? If you think it's a subkey used by the Windows shell, give yourself a gold star. Expand the shell subkey. Here's where it gets really exciting. Okay maybe I need to get a life. Anyway, the subkeys appearing under the shell subkey will resemble the items appearing in the context menu in the Windows Explorer. Bingo - you're there! When you right-click a file in the Windows Explorer, it comes to the shell section for the type of file you right-clicked on and build the context menu dynamically based on what it finds. The actual text of the context menu can be in two different places. The first is the actual subkey name appearing under the shell subkey. The second is the value that appears in the (Default) value. From one of these two places, the context menu is built and shown.

    The next thing that would happen in the Windows explorer is probably you clicking on one of the menu items. Let's use Open as an example. Go back to the Registry Editor and expand the Open subkey under shell. You'll see another subkey called command. If you click on the command subkey, you'll see that the (Default) value has a value. If you double-click (Default), the Edit String dialog will open. If you're using the default text file editor installed by Windows, you'll see Notepad.exe somewhere in the string value. That means that Windows will use the Notepad.exe application to open files with the .txt extension. But how does Windows know what file to open? Well, the other thing you'll see, along with notepad.exe, is %1. %1 is a token that will be replaced on the fly with the name of the file you right-clicked on. So, let's say you were in the root on your C drive and you right-clicked on a file called foo.txt. When you click the Open item, the shell launches notepad passing c:\foo.txt on the notepad command line, which instructs notepad to open the file. That's all there is to it! Take a quick look at the print subkey under shell. This item provides the command line for printing text files. You see how it's done. The Shell calls notepad and passes a /p and %1 (the file name) on the command line. The /p instructs notepad to print the file it opens. Piece of cake right?

    But Why?
    By now, you're probably wondering what all this has to do with VB. Well, I use this information to help me work with files that we VBers typically work with. Let's say you create quite a few DLLs in you current assignment. If you do, you know that quite often, you find yourself registering and unregistering DLLs while you test. You may open a DOS box or you may open the Run dialog, but you end up somewhere typing in

    regsvr32 C:\the very long\path to a DLL\I wrote in VB\yesterday\foo.dll

    What a drag eh? Well, never again. What did we just learn? How to get the Shell to execute a command for us, based on the file extension. Ah, I see the lights coming on. Piece of cake right? Open the Registry Editor (if it isn't still open from before) and navigate your way to


    If there isn't already a subkey called shell under dllfile, create one. Under shell, create two new subkeys; Register and Unregister. Create a command subkey under each of these. In the (Default) value for the shell\Register\command subkey, enter

    regsvr32 "%1"

    For the shell\Unregister\command (Default) value, enter

    regsvr32 -u "%1"

    These command lines, as I'm sure you know, register and unregister COM DLLs. To try them out, open the Windows Explorer and locate one of your VB DLLs. Right click on it and, if we've done things right, Register and Unregister will appear in the context menu. Click Register and you'll see the familiar DllRegisterServer...succeeded message. You did it! You'll never have to type that command out again.

    Other Ideas
    Now that you have the basic idea, what else could you do? Well, I often find myself opening project files or forms in Notepad to look through them for something when I don't really feel like opening a new instance of VB. So what I did was add a new shell subkey for all my VB-related files like .cls, .frm, .vbp, and .vbg. As a quick refresher:

    - navigate to HKEY_CLASSES_ROOT\.cls (for example)

    - you'll see the (Default) value says VisualBasic.ClassModule

    - navigate to HKEY_CLASSES_ROOT\VisualBasic.ClassModule\shell

    - add a new subkey called Open with Notepad

    - add a subkey under this called command

    - set the (Default) value to

    notepad.exe "%1"

    You Can Take It From Here
    You can apply this same set of steps to just about any file type in your system. Then, once you've added all the necessary subkeys and commands, you can just right click a file to get at your most commonly used commands! If you ever need to remove one of the commands you added, just delete the subkey under shell and it will go away.

    This week's article may not be directly related to VB, but it is directly related to your productivity. The faster you can get things done, the more productive you'll be. It doesn't matter whether it's coding that new DLL, or registering it and unregistering quickly while you're testing; both add to your productivity!

    This article has been republished with permission from EZ Programming Weekly. To subscribe, send an email to
    personal info | online resume | project details | vb downloads | contact | articles
    Copyright 2001 by Earl Damron