Nice start :t
In all my browsers, when I redirected to another page after opening a previous page, it would simply close my browser (*Note: after switching to standard windows behavior), requiring reclicking to reopen the browser. Hence I lost a large group of tabs opened on various subjects I was studying when I tested your app. It also refused to open any browser maximized, even if that was the previous state of an already opened browser. My .htm files are not (by default) associated with any browser on my machine, rather to my own app (Drawer.exe) giving me a choice of any of my browsers, editors, etc., to open with. When I bypassed my Drawer app your app was highly inconsistent in what occurred from one click to the next. Sometimes a separate window, other times a new tab, other times closing browser it never opened to begin with while failing to open the selection I chose. This problem persisted for all browsers. This was due, apparently, to the default behavior of wanting to close previously opened instances of my browser without first knowing whether that previous instance was still open or not or whether it involved opening a new tab in an existing browser. My default open pointing at Drawer.exe actually completely tamed this behavior (if parent/child redirection wasn't specified), since it automatically closes after any choice is made removing the handle for your app to close.
If you stripped "xHelp/" from the full path and replaced the last instance of "/" with ".chm::/" and ShellExecute that string it will open the proper <filename>.chm location, at the page location, using the standard windows help file reader, hh.exe. The browser then wouldn't be an issue. You can also avoid ShellExecute by prepending the path string with "hh.exe ", but not really necessary. If the same .chm file is being redirected to another page, and a previous instance has been opened, then passing the Hinstance from the previous ShellExecute should allow you to avoid opening a separate instance of hh.exe, and wouldn't require that you exit the previous instance. For multiple <filename>.chm opened you would need an array of previous Hinstance's from ShellExecute with the previous <filename> associated with its own Hinstance. Even in the event that a separate instance of hh.exe is required, for a differing <filename>.chm, I would not want the previous instance automatically closed under any circumstances.
If you want to stick with opening the .htm files using the browser I would still absolutely avoid closing the previous instance, and merely let the new .htm open in another tab, or browser, per the users browser configuration. Firefox even has plugins to avoid multiple instances of the same page. There are also techniques for reusing the same tab in various browsers, but requires knowing which browser is being used, and in some cases using command line switches, activeX for IE, or possibly addons in FireFox. Too much trouble in general.
Personally I would go with the default hh.exe on the existing .chm files, to maintain consistency of expectations. Then use the Hinstance arg to avoid multiple windows without closing the previous window, but with checks to see whether that Hinstance still exist or not and/or corresponds to a differing <filename>.chm. I would never outright close a previous instance of anything under any circumstances. These things need fixed before a consistent operation can be achieved irrespective of the local user configuration. In my own configuration fixing these configuration dependencies for various standard user configurations would also greatly extend my configuration options using my Drawer app beyond simply taming the inconsistent behavior.
After writing a single app to completely replace all file associations in windows, with configurable per selection standard input/output redirection, I am exceptionally good at this stuff. Though I never used ShellExecute to accomplish it, since that defeated my goal of entirely replacing windows file association system and would create an infinite open with loop of choices, because Drawer.exe would then always point back to itself. Though this is allowed, per choice configuration, if you want to open a second set of choices for a given Drawer, and can chain parent/child redirection, if needed, through any arbitrary number of Drawer.exe instances.
