|
[ Go to May 1997 Table of Contents ]
Launch Control Exclusive tips make your Win95 document icons launch the correct application.
Some recent visitors to WINDOWS Magazine's CompuServe forum (GO WINMAG) expressed dismay about the way Windows 95 handles file associations. Actually, it's not Windows 95 but various applications that cause the problems. As you know, you can launch an application in Win95 by double-clicking on a document icon (a word processor file, PowerPoint presentation and so on) associated with it. Unfortunately, there are two potential problems with such associations. First, a newly installed application may launch when you double-click on a document icon that previously launched an older application. If this hasn't happened to you yet, it will. That's because some applications consider themselves about the most important thing that's ever happened in your life. These greedy apps grab every association they can get their hands on. Apparently app designers know what's best for you, since you're not even asked for your preference. Second, let's say you install yet another new application because it manages certain document files better than your former choice. This time, you want the app to assume some existing associations, but it doesn't. Being well behaved, it leaves your existing configuration alone-and you're stuck with it. Of course, it's no great trick to simply open any application and then load the desired file into it. It's also no big deal to open Explorer's View menu, select Options and then the File Types tab, to edit an existing file type. But since these are not always the best choices, here's a look at some other alternatives. I'll use Microsoft's Internet Explorer 3.0 and Quarterdeck's HiJaak Pro 4.0-IE and HJP for short-to illustrate how some association problems can be identified and then resolved. These examples should generally apply to other apps that use associations. Application associations As already noted, double-clicking on any document icon should always open the correct application for that file. Now all we have to do is define "correct." For example, on a system with only IE installed, double-clicking on a GIF or JPG file icon will open the browser and display the selected image. If only HJP is installed, the same action will display the image in a HiJaak Pro window instead. In either case, this is just what you'd expect to happen, since the resident application assigned GIF and JPG file associations to itself as part of its setup procedure. Let's assume you have one of these applications installed and working properly. What should happen when you install the other application? The simple answer is: It depends. If I install HJP in addition to IE, I'd prefer that HJP pick up the graphics file associations, rather than continue viewing GIF files in the browser window. In other words, the most recently installed app should take over associations formerly assigned to an older app. Not so fast. What if I installed HJP first, and then IE over it? I would not want the new application to rewrite the old associations. IE is very nice for browsing, but I wouldn't want it to take the place of the HJP associations. I would, however, want HJP to take over previous IE associations-unless I had yet another graphics application. So, what's a poor software designer to do? No matter what decision is made, it will be the wrong one for at least some users. That's why you'll want to know how to reconfigure your system so that the right app opens when you double-click on a document icon. With that in mind, I installed HJP on one system and IE on another. Here's a look at what goes on behind the scenes, along with some suggestions on how to rewrite the script so that all the players do what you want them to do. First, on that HJP-only system, the setup procedure added new .gif and .jpg subkeys under the HKEY_CLASSES_ROOT key of the Windows Registry, and in each case the new subkey's contents pane shows the following identical information: Name: (Default) Data: "HiJaak.Image" This data serves as a pointer to a new HiJaak.Image key in the same Registry section. The key leads to a small collection of subkeys that support various HiJaak functions. At the bottom of the list, a shell\open\command key specifies the path and filename for the appropriate executable file. So, if you double-click on a file with a GIF or JPG extension, Win95 consults the .gif or .jpg key as appropriate and discovers that it points to the HiJaak.Image key, and then launches the specified executable program (HIJAAK.EXE in this case). The application opens and loads the selected file, ready for editing. By contrast, if IE is installed, the .gif subkey points to a giffile subkey, and the .jpg subkey points to a jpegfile subkey, and each leads to a command subkey that launches Internet Explorer. Therefore, the IE browser window displays either file type (GIF or JPG) if the appropriate document icon is double-clicked. As a quick digression, I noticed that the entire subkey structures under the giffile and jpegfile keys are identical, but because they are separate, one might be customized later on without affecting the other. Next, I installed IE on the HJP system and vice versa. In both cases, the new application left the old associations in place, so I got what I wanted on the HJP system (it retained its associations) but not on the IE system (HJP did not grab the associations). If both IE and HJP were more aggressive, each would have snatched the other's associations, and I would have been no better off than before. But, given the situation on the IE machine, let's see what I can do to coax HJP into picking up those GIF and JPG file associations. Fortunately, there's nothing to it. Since the HJP setup procedure wrote that HiJaak.Image key into the Registry, all I need to do is redirect the GIF and JPG subkeys to it, instead of to their current giffile and jpegfile keys. To do so, just open the Registry's HKEY_CLASSES_ROOT key and then open the GIF subkey. Double-click on the (Default) entry in the Contents pane on the right-hand side of the window and type HiJaak.Image in the Value data box, thereby overwriting the former giffile entry. Click on the OK button and then do the same thing for the .jpg subkey. From now on, if you double-click on a file with either extension, it will open in HiJaak Pro instead of in Internet Explorer. Microsoft urges you not to edit the Registry directly and provides an alternate method to accomplish the same thing-almost. Highlight any GIF or JPG icon, hold down the Shift key and click the secondary mouse button to open the context menu. Select the Open With option, highlight HIJAAK in the program list, put a check mark in the box next to "Always use this program ..." and click on the OK button to conclude the operation. In this case, I think it would be better to risk Microsoft's displeasure and edit the Registry. The reason is, the alternate method leaves the .gif key pointing to the giffile subkey, but then changes that key's command subkey so that HIJAAK.EXE is executed instead of IEXPLORE.EXE. In other words, it ignores the entire HiJaak.Image subkey structure in favor of this newly modified giffile structure. As a potentially troublesome side-effect, if an .xyz key (where xyz is some other extension-perhaps one not yet familiar to you) also points to the giffile subkey, then a double-click on a FILENAME.XYZ icon will also launch HiJaak Pro, which may not be desirable. I'd rather leave the command line as is, and rewrite the .gif subkey so that it points to the HiJaak.Image key, as it would do if HJP had been installed as the first application. By installing HiJaak Pro on two machines as described above, I discovered the .gif -to- HiJaak.Image key relationship on one machine, and then used that information to edit the Registry on the other one. It wasn't the most practical thing I've ever done, but it worked. Meanwhile, I still must solve one riddle for this column: How do you cope with a misbehaving application-one of those whose setup procedure grabs the existing association for GIF files? Again, the problem is that the .gif subkey now cites the wrong subkey, which in turn leads to a command subkey that opens the wrong application. To compensate, you need to restore the original data, but you don't know what it was. So, how do you find it? Fortunately, this, too, is reasonably easy, even if a bit of a nuisance. In this specific example, the GIF file formerly opened in HiJaak Pro. So just find the key structure whose command subkey cites HIJAAK.EXE. To do that, open the HKEY_CLASSES_ROOT key and scroll down beyond the last subkey whose name begins with a period. This saves a bit of time-none of these file extension keys will have what you're looking for, so there's no point in searching them. Highlight the next subkey (to begin the search at that location), then open the Registry Editor's Edit menu, select the Find option, put a check mark in the Data box only and search for HIJAAK.EXE. Ignore all successful finds until you reach one where the Key pane shows a highlighted open "command" subkey. The Status bar at the bottom of the Registry Editor window will read as follows: My Computer\HKEY_CLASSES_ROOT\xxx\shell\open\command The xxx segment is what you're looking for, and in this example it's HiJaak.Image. So now all you need to do is edit the .gif subkey's Data column, which is higher up in the key structure. Change the entry from whatever it is (probably giffile) to read HiJaak.Image, and you've restored the original association. The confusion isn't over yet. If an application is uninstalled, it may leave one or more empty file-extension subkeys in the HKEY_CLASSES_ROOT section of the Registry. For example, if HiJaak Pro is uninstalled, the GIF subkey's Contents pane will look like this: Name: (Default) Data: "" Name: Content Type Data: "image/gif" For some other application, the last line above may contain a different Data entry, it may be missing, or there may be other lines instead. The point is, the uninstall procedure removed the citation in the (Default) line, but left the subkey itself in place. If you subsequently reinstall the application, or install some other application that is supposed to pick up the GIF file association, it may not do so. Since its setup procedure sees the existing line-even though it has a null ("") value, it leaves it alone. To illustrate this, temporarily rename your existing .gif subkey as .gifx (for this example), then write the following little TEST.INF file: [version] signature="$Chicago$ [DefaultInstall] AddReg=TestKey [TestKey] HKCR,".gif",,2,"giffile" HKCR,".gif","Content Type",2,"image/gif" Save the file, open its context menu and select the Install option. This creates a new .gif subkey whose Contents pane displays the two lines in the [TestKey] section above, as would happen if these lines were part of an application's setup procedure. Next, delete the giffile entry in the .gif key's Contents pane, which is what would happen if the same application were subsequently uninstalled. Now select the Install option once again, to simulate the effect of reinstalling the same application or of installing a new one. This time, the Install procedure has no effect, and the nulled (Default) line is left as is. As a result, the desired association is incomplete, and a double-click on a GIF icon will prompt you to choose the program you want to use. Again, I recommend against continuing this procedure. For example, assuming you've just reinstalled HiJaak Pro, selected it from the program list and checked the "Always use this program ..." box, the GIF file will open in HJP and all seems to be well-until you look a bit closer. The first thing you'll notice is that the Registry entry is not what you might expect. The .gif subkey cites neither the restored HiJaak.Image key nor the former giffile key. Instead, it shows a unique gif_auto_file citation, and sure enough there's a new key structure with that name. But all it contains is a simple shell\open\command key structure, and there's no DefaultIcon or Shellex key structure. As a result, a GIF file will show one of the Win95 generic icons, and its context menu will lack all the options appropriate to a GIF file. To fix things up, simply edit the .gif subkey to cite the HiJaak.Image key. Then delete the gif_auto_file key, which is no longer needed. The same procedure will work even if you don't install a new application (or reinstall the one just uninstalled). To return to a former application that's already in place, just search for the command subkey that runs its executable file, then edit the GIF key citation as described earlier. When you're finished experimenting, it's easy to return to the former configuration. Erase the existing .gif key structure, and rename that temporary .gifx key back to .gif. Once again, the items listed under that key will take effect. Senior Contributing Editor John Woram is the author of "The Windows 95 Registry: A Survival Guide for Users" (MIS: Press, 1996). Contact John in the "Optimizing Windows" topic of the WINDOWS Magazine areas on America Online and CompuServe, or care of the editor at the addresses here.
|
