CHM Help opened with F1 from some dialogs, after closing then not released by TC, and not re opened with F1 if unlocked

[Usher]

Could it be some 3rd-party software that's interfering and prevents the WinAPI internals from unlocking the CHM properly?

Maybe CHM is locked by some TC plugin (wcx, wlx)?

[Flint]

2DrShark
Ah, that's what I've missed! I was calling from the main window; didn't read the steps properly. Thanks, I reproduced it with the dialog.

[petermad]

Are you sure you're opening help with F1 while in Pack files (or other TC's) dialog?

I can reproduce the problem both when pressing F1 and when clicking the Help button (Windows 7)

[petermad]

2Usher

Maybe CHM is locked by some TC plugin (wcx, wlx)?

It also happens with a clean ini file (no plugins).

[ghisler(Author)]

Since this seems to be an intentional "feature" of the HtmlHelp function, I think that we shouldn't try to fight against it. I will therefore move this thread to "Will not be changed" soon.

[DrShark]

While the topic is not yet moved, maybe following information will be helpful:

Using a process explorer you can actually see that Internet Explorer dlls will be kept in memory, even after HH_CLOSE_ALL closes the help window - But only if you use the HH_HELP_CONTEXT command! Stick with HH_LOOKUP_TOPIC and the dlls will be unloaded as expected and the chm-file lock disappear. My best guess is that after reading the context mapping information "somebody" forgets to close an internal stream in the chm-file...

More info is here: https://www.codeproject.com/Articles/3618/Htmlhelp-Forensics

[ghisler(Author)]

Interesting indeed. Unfortunately I couldn't find any documentation of HH_LOOKUP_TOPIC, not via Google and not in the linked article.
Do you have any information on how to use it?

[DrShark]

Unfortunately I couldn't find any documentation of HH_LOOKUP_TOPIC, not via Google and not in the linked article.

It's only mentioned in article, but in sample sources HH_DISPLAY_TOPIC is actually used. I'm not a programmer so cannot say how useful this is.

[Flint]

As far as I understood, he simply parses the CHM internal structures (which are quite simple) to manually fetch the page name assigned to the specified index, and opens this page directly instead of relying on HH_HELP_CONTEXT (which basically does the same, but with the file locking bug).

P. S. I foresee a possible shortcut, which is to hardcode the list of pages directly into TC, and use them instead of indices; but that is to be avoided. Many of the translated CHM help files have different structure to the original one (mostly, the HTML files are put into a subdirectory), so the hardcoded list won't work for them.

[ghisler(Author)]

I see, so that's why I couldn't find any documentation about HH_LOOKUP_TOPIC!
HH_DISPLAY_TOPIC uses the topic name, so I can't use that directly because it can differ between languages.

Is it really worth to add a manual CHM parser just to avoid the locked file?

[DrShark]

HH_DISPLAY_TOPIC uses the topic name, so I can't use that directly because it can differ between languages.

I think you can at least use it directly for English (and maybe also German, French) help.

Is it really worth to add a manual CHM parser just to avoid the locked file?

I'm not a programmer so cannot say how much efforts it will require. But I think for the way Total Commander uses context help (one help topic for one TC window or dialog), HH_DISPLAY_TOPIC is a best choice. HH_HELP_CONTEXT which locks the file and keeps help loaded in RAM may be better if different help topics describe different UI controls on same window/dialog, and the help topic for each control is opened by moving "?" pointer to certain GUI control (screenshot).

[ghisler(Author)]

I have added this now, but it doesn't seem to work on Windows 7. It works fine on Windows 10 1803 and 1909, though.

[DrShark]

18.02.20 Fixed: Help file would get locked when opened with a page other than the main index (e.g. Keyboard shortcuts) -> use HH_DISPLAY_TOPIC instead of HH_HELP_CONTEXT (32/64)

I have added this now, but it doesn't seem to work on Windows 7. It works fine on Windows 10 1803 and 1909, though.

I can confirm on 32-bit XP/Vista/7 the help file is still locked (cannot check on Windows 10 right now, as well as on older Windows versions; also I didn't check whether new way of opening help affects translated CHM help files with different structure to the original one).

[Flint]

That's funny, for me it stays locked only in 32-bit version of TC. The 64-bit one unlocks the CHM successfully. I tested it in Win7 x64 and Win10 x64 1909, results were the same.

Also I confirm the correct work of the translated Russian CHM, which has different internal file structure to the original one.

[ghisler(Author)]

for me it stays locked only in 32-bit version of TC

Ah, it's actually a mistake on my part - I had disabled the function in the 32-bit version because it seemed slower than using the old method, but this wasn't the case. I removed the comments from the function via "Undo", but the compiler didn't pick it up (a known bug of Delphi 2). After re-saving the file, it now works on Windows 7 too!