I can't launch HTML Help files, that is, "Compiled Help Module" files (.chm). When I double-click such a file, the viewer opens instead. In Windows Explorer, these are set to open with something called "Microsoft® HTML Help Executable". So I go into Opus to set this file type, but I don't know where to look for this Help Executable program. Is there some easy way to just ensure that Opus uses the same file type information as Windows? I've never had this problem with any other file type. TIA
Sounds like something trashed your default file type settings for .chm, because I'm certain I never manually set mine and it opens fine. In the Dopus file type settings for this extension on my system I have "C:\WINDOWS\hh.exe" %1 set as the 'open' action.
But just so you know, you can usually figure out what Windows is actually doing if for some reason Dopus is not behaving the same way by checking out the registry like so:
- Open regedit and look for the extension of the file in question (.chm) under HKEY_CLASSES_ROOT (HKCR)
- In the reg key for that extension, the (Default) string value will be the description name for that file type which should also have a seperate key under HKCR (chm.file)
- Under the key for this file description, there are usually the following series of sub-keys: shell\open\command in which the (Default) string value is the actual command Explorer is running against the file type (in this case as above "C:\WINDOWS\hh.exe" %1)
So, check your Dopus file type settings for .chm, and let us know what you see for both the open action as well as the dblclk event. If the open action seems to be set right, then you could try setting the same command for the dblclk event (mine is a WinXP system, so maybe your command is different though?). But before you do - I'm curious what you see if you right mouse click on the file in Dopus? Do you see a bold Open context menu option? And if so, does clicking it open the help file like you'd expect?
I found this link that might be relevant to whatever happened to you? Search for chm.file in that article if you're interested...
It's possible something hijacked the file type descriptor for .chm files on your computer and this has somehow messed with Dopus file type settings - a variation on this sort of thing was happening to me when I was trying different zip/archive applications and stuff I manually set up in Dopus file types for zip files while the extensions were defined as "WinZip File" didn't work anymore because the file was later being treated as a "PowerArchiver Zip File"...
As yet another side note- there can be other commands associated with file types in the registry under that shell key I mentioned, and the 'default' command is not always Open like Dopus used to assume but which was fixed up in v8.1. By default the... er.. 'default' action is indeed Open, but you can tell if it's set to something else by looking in the shell keys (Default) string value - where there will usually be the name of some other key underneath shell whose command will be run on double clicking the file type.
Man, I type too much? Tanis, you have a limit on characters for a single post?
Thanks for the reply - well, I fixed it by assigning "hh.exe" to .CHM files - my biggest problem was I didn't know the name or location of this executable. Now the help files open properly when I double-click (yet when I go into file types there is still nothing listed under any action or event, all items say ).
Thanks for the reply - well, I fixed it by assigning "hh.exe" to .CHM files - my biggest problem was I didn't know the name or location of this executable. Now the help files open properly when I double-click (yet when I go into file types there is still nothing listed under any action or event, all items say ).
Just curious - what did you to for "assigning "hh.exe" to .CHM files" - use the Open With dialog or something? Whatever way you used might not have registered hh.exe as the command to run as an 'open' action in the registry, but perhaps just registered it as the (Default) shell command, which wouldn't necessarily show up in Dopus file type editor depending on whatevr name the command was registered as. You could tell from the registry keys I mentioned if you were curious and wanted to find out...
what did you to for "assigning "hh.exe" to .CHM files" - use
the Open With dialog or something?
I think I played around in Opus file types until I got an "Open With..." dialog and manually chose hh.exe. It could have been from outside Opus too - I don't remember exactly.
Interesting... In regedit, the value of .chm\shell\open\command is the following:
"%SystemRoot%\hh.exe" %1
But Opus continues to claim there is no open action. Also regedit shows the file type description as "Compiled Help Module" while Opus defaults to "CHM File". Am I wrong - it seems like there's a disconnect between file types in Windows vs. Opus? I suppose I could manually enter "%SystemRoot%\hh.exe" %1 under the open action, but I don't want to do it twice for this or any other file types.
Aha - you've just stumbled across the likely answer to why this may have happened to you. What you've just observed about the description for .CHM files within Dopus being different than what appears in the registry is possibly the reason Dopus did not show an 'open' action defined. If you go look for the description Dopus has for .CHM files in the registry (CHM File), you'll probably see that there is no shell\open command there either...
I'm not sure why Dopus sometimes seems to have file type actions hijacked out from under it's nose, but I know that programs often modify the filetype 'Description' for files they 'take ownership of' under that files extension in the registry (to suit their own purposes). It seems that Dopus' filetype description never gets updated in these cases and at one time I thought Dopus maybe just didn't dynamically 'look up' filetype description linkage for extensions it 'already knew' about or something.
Whatever the method used in Dopus and whatever might actually cause the sort of problem you had - I know for a fact that user defined Context Menu commands added within Dopus to a particular system file type fall prey to filetype description changes... used to happen to me all the time with .ISO files and .ZIP files as I would evaluate and switch between different ISO and archive applications like WinImage, ISOBuster, WinZip, WinRAR and PowerArchiver.
No idea what you are seeing here. Opus uses the same file types as other programs - apart from the half dozen or so special Opus only file types.
These are read from the System Registry when required. Possibly some other application is modifying the registry underneath Opus although I've never this happen. There are known cases where running applications get parts of the original version of the system registry as when they are run, but not for file types AFAIK.
To alleviate any such concerns, 'quit' Opus fully (tray icon - Exit) and rerun and see what happens.
I'v seen the stuff steje is talking about. In fact, I'v been in one folder, and dblclicked and my main text editor opened the file, while on the destkop, a dbl click would open it in notepad. Odd... (And, no, I cant reproduce that at the moment)
Speaking of associations... I associated .dbf files with a program and now I dont want it anymore. I cant seem to get DOpus to be the viewer anymore. When I dblClick a .dbf file windows pops up the "choose an application to open this filetype" dialog.
Any hints?
Thanks,
-Andy
Greg - it's a weird issue man. In fact, what I was describing having happened to me proves that what Rhywun was seeing shouldn't reallt ever happen.
Case in point:
If I have WinImage installed, .ISO files are described in the registry as 'DiskImage' files. If I then manually add a command like FileType CONTEXTMENU {70B28949-EC23-4D00-A411-AD8A1B3A8A5A} CONTEXTFORCE to the .ISO System File Type, it properly invokes the awxDTools extension for Daemon-Tools. The command is also visible in the registry under the HKCR\DiskImage\opus registry key.
If I then install another application like IsoBuster which modifes the registry description for .ISO files (to IsoFileImage) Dopus properly 'follows' the new file description linkage and launches IsoBuster on double-click instead of WinImage, but the Daemon-Tools extension is no longer getting invoked - e.g. the file type descriptor has changed and the Dtools command is not present under the file types 'new' descriptor key.
codeguy- I'm not sure if .dbf files are supposed to be part of Dopus 'Recognized Images' or not, but the Dopus command that displays images in the internal viewer is show. So you should be able to just make sure that 'show' runs either directly against .dbf file extensions on dblclk event, or if Dopus previously showed the files before you installed this other program, then maybe you can simply get rid of whatever is currently being called for dblclk or open.
Thanks steje, that did the trick. Looks like .dbf is part of the QuickView dll's, which were uninstalled when I uninstalled powerDesk... wasnt an association problem after all.
-Andy