Forums Bug Reports .chm files locked by mIRC

If you run an help file from mIRC, for example ircintro.chm, then close that help file, mIRC keeps the file locked (you can't delete the file) if the mIRC help file mirc.chm is still running.

1) run the mIRC help file mirc.chm
2) run ircintro.chm (/ircintro)
3) close ircintro.chm
4) try to delete the file ircintro.chm in the mIRC folder (/run .), explorer says the file is open in mIRC
5) close mirc.chm
6) you can now delete the file in explorer

Thanks for your bug report. This has been discussed before. mIRC passes the help file name to the Windows Help system which is performing its own lock on the file until the calling application exits. mIRC has no control over this.

Ok, well in this report the file being locked is not the file being used (though indeed, it's not related the the mIRC help file specifically).
You say the application needs to exit to release the file but closing all help files opened from mIRC is sufficient.

This is not for mIRC's own help file but to handle my own custom help file. CHM file are blocked by default, they need to be unblocked, which is not great for sharing and widespreading. One way around the block is to download the file manually from mIRC ($urlget works).
So I wrote a small code which updates the help file from an http server, but this issue prevent me from updating if any other help file (typically the mIRC help file) is still open.

Googling this issue does not give any result. Or could it be that you need to release resources when we close an help file or something?

Is it possible to extend the /winhelp command to take new parameters/switches, which could be used to close the help file, aka "/winhelp -c <name>" and "/winhelp -n name file topic", so that at least script can handle this situation better? Maybe a $winhelp identifier as well to know what's open.

I'm afraid there is no way around it - this has been looked into before, several times. The file is locked by the Windows Help system until the application exits regardless of what the application does.

Alright, thanks for the answer. I really don't understand this design from Windows

As far as I know, it is due to a bug with how Windows handles HH_HELP_CONTEXT context-based lookups.

You can find a technical explanation here, where it also describes how to get around it - by decompiling the CHM file using the ITStorage COM interface, mapping context ids to topic links, and then using HH_DISPLAY_TOPIC to display the topic instead.

I generally prefer to avoid using barely documented COM interfaces - this one has so few google hits that it might as well not exist. And decompiling a CHM seems a little over-the-top for just opening a help file :-) But I have implemented a minimal version and it seems to work fine on XP through to Windows 11, so I am going to add it to the next beta. It will need to be tested on a variety of CHM files to make sure it's okay.

Great news, thanks for looking into it.

Feedbacks.

I thought the fix you added had solved the issue but I just got the issue again, custom help file ran with /winhelp locked by windows because the mIRC help file was also running, closing the mIRC help file solved the problem.

Thanks for the feedback. The change that was meant to fix this issue uses a method that is undocumented, as I mentioned in my previous post, and it is literally the only method available to get around this Windows issue. If the fix is not working, I would really prefer to revert it. Please confirm in a follow-up post if it is or is not working for you.

Well all I can say is what I've said in my previous post. Since the fix I've used this help file via my alias in combination of running the mIRC help file alongside it more than 200 times, probably in various order of opening, without any problem, until two days ago.
I would prefer if you were not reverting the fix for now, as I'll probably update to from 7.77 to the next beta to play around more with it on lastest version. You can eventually revert the fix in the next stable release if nothing great comes out of it.

That being said, the link to the fix in your previous post definitely seems confident in the fact that using topic instead of context id makes the bug go away. You mentioned a minimal implementation of it, could it be that mIRC is still using context id in some cases?