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

[DrShark]

To reproduce:
1. Open Pack Files dialog.
2. Press F1 there: CHM help will be opened.
3. Close help, then close pack dialog.
4. Try to replace %commander_path%\TOTALCMD.CHM with other TOTALCMD.CHM file:
TC will show Access denied dialog.
You can also check TOTALCMD.CHM file with tool like Unlocker: it will show TOTALCMD.CHM is used by TOTALCMD.EXE.
5. (Optional) Use "Unlock" button in Unlocker started for TOTALCMD.CHM to unlock it from being used by TOTALCMD.EXE and try to call help with F1 in Total Commander again: it will fail, it seems to make it succeed the restart of Total Commander is required.

[petermad]

This is new to TC 9.50 final, it is not present in TC 9.5rc2 or TC 9.5rc2d
It applies to both 32- and 64bit TC 9.50.

[ghisler(Author)]

This is new to TC 9.50 fina

Not confirmed, it happens with TC 9.22a too!

It doesn't seem to be a bug either, but some kind of caching done by the HtmlHelp function. The only difference between F1 in the main form and F1 in a dialog box are the parameters passed to HtmlHelp:
Main window call:
HtmlHelp(0, HelpFileName, HH_DISPLAY_TOC,0);
Dialog box:
HtmlHelp(0, HelpFileName, HH_HELP_CONTEXT, ContextID);

I have also tried to call HH_DISPLAY_TOC first followed by HH_HELP_CONTEXT, but it has the same problem.

[petermad]

Not confirmed, it happens with TC 9.22a too!

I tried again - you are right - sorry.

[DrShark]

It doesn't seem to be a bug either, but some kind of caching done by the HtmlHelp function. The only difference between F1 in the main form and F1 in a dialog box are the parameters passed to HtmlHelp

Can this behavior be fixed? Can you please also check why calling help with F1 then fails if to unlock TOTALCMD.CHM file from TOTALCMD.EXE using Unlocker (see step 5)? Maybe if you'll make it work in this case, I guess it would possible to use Unlocker's method for unlocking help file opened by HtmlHelp called with parameters...

[ghisler(Author)]

Honestly, I don't know. Maybe it's mapped into memory, or the help process has some higher priority to avoid tampering, no idea.

[browny]

Unlocker closes file handle, and help system would not not try to reopen the file.
In most cases, closing and re-opening help files would waste more resources than keeping file handles open.
Sources for Delphi's help system could probably be found somewhere in rtl subdirectory.

[ghisler(Author)]

TC does not use the Delphi help system here. I'm using Delphi 2 for 32-bit, and it only supports HLP files. Instead, I make just a single function call:
HtmlHelp (as described above)

I have also tried to call HtmlHelp with parameter HH_INITIALIZE first to run html help on the same thread as the main window, but this didn't make any difference either.

Unlocker closes file handle

Maybe it's protected somehow by the html control, so the content of the page (which is essentially a web page) cannot be manipulated?

[DrShark]

It doesn't seem to be a bug either, but some kind of caching done by the HtmlHelp function. The only difference between F1 in the main form and F1 in a dialog box are the parameters passed to HtmlHelp

If it's not a bug, then it's strange that such "caching" doesn't happen if to call HtmlHelp function without parameters.

Anyway, I experimented a bit more with this: after unlocking main help file I changed language to open localized help (wcmd_<lng>.chm) with F1, it works.
But after changing TC language back to English it doesn't open main help no matter what: remaming/moving, or even permanent deleting the TOTALCMD.CHM and then restoring it to %COMMANDER_PATH%, F1 or cm_HelpIndex fail to open it.
But opening it with HH.exe from Total Commander's command line using ITS aka InfoTech Storage URI format:
hh its:%COMMANDER_PATH%\TOTALCMD.CHM::main_index.htm
works (without hh.exe at start of that line the chm is being opened in Internet Explorer).

[ghisler(Author)]

It isn't a bug, just a misfeature of the HtmlHelp function.

When changing languages, TC unloads the help to load the new one. I could unload the help also when it's no longer needed, but I don't know when - the user may have just switched back to Total Commander and want to keep the help open.

[Flint]

2ghisler(Author)
I've had a quick look at the API; it seems that HtmlHelp should return the help window handle. When the TC window receives focus, you could check by that handle, if the help window is still open. If it's closed, then the CHM may be safely unloaded.

[ghisler(Author)]

I have just tried it, it doesn't help. Here is what I tried:
1. Check IsWindow() -> the help window is still there, just hidden
2. Check IsWindowVisible() -> works
3. Call HtmlHelp(0, NULL, HH_CLOSE_ALL, 0) -> the help file is still locked
4. Added c all to HH_INITIALIZE at start and called HH_UNINITIALIZE after HH_CLOSE_ALL -> the help file is still locked

So the only way to unlock the help file seems to open a different help file!?

[DrShark]

I have just tried it, it doesn't help. Here is what I tried:
1. Check IsWindow() -> the help window is still there, just hidden
2. Check IsWindowVisible() -> works
3. Call HtmlHelp(0, NULL, HH_CLOSE_ALL, 0) -> the help file is still locked
4. Added c all to HH_INITIALIZE at start and called HH_UNINITIALIZE after HH_CLOSE_ALL -> the help file is still locked

Maybe it will work if to try following: if help window is hidden, unlock TOTALCMD.CHM using Unlocker's method, then close Help using calls from your steps 3/4, and on next F1 keypress try to open it again?

[Flint]

By the way, I've tried to reproduce the issue, and could not. On my system the CHM file's handle is automatically closed whenever I close the help window (I've been monitoring it via Process Explorer), and the CHM file can be deleted/overwritten.

I've tried it on 32- and 64-bit version of TC 9.50; Win7 SP1 x64 (and also in an old Win10 virtual machine with TC 9.21a). Tested with both the original English help and the Russian one (Language\wcmd_rus.chm). I'm not sure what I'm doing wrong here. Could it be some 3rd-party software that's interfering and prevents the WinAPI internals from unlocking the CHM properly?


2ghisler(Author)
Maybe unloading the hhctrl.ocx could help? Although, there are some mentions in the Internet that this may cause issues if not done properly; I didn't have time to get into details, but it seems there is a working way of doing it.

[DrShark]

By the way, I've tried to reproduce the issue, and could not. [...] I'm not sure what I'm doing wrong here.

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