ChmWindowD
Under FF, standard windows file association, it appears to work well as you seem to expect.
Under IE, standard windows file association, it still open every click in a new window requiring them all to be manually closed.
Under Iron (Chrome) any spaces in the filename get delimited as separate pages to open in different tabs. Hence "Bare Bones Dialog" attempts to open 3 tabs at "file:///C:/Masm32/help/xHelp/imdialog/Bare", "
http://bones/", and "
http://dialog.htm/". Using choices with no spaces it opens each each choice properly but in its own tab leaving the previous tab. The entire browser then closes when you exit the app.
Opening with my Drawer app changes none of the behavior above, and can no longer prevent you app from closing my browsers. Except IE which never closes anyway.
I could also test in Opera, Maxthon, and others, but would need to disable some significant modifications to make it meaningful.
____
It's a good idea to think through exactly how you expect it to work. If you are wanting it to work for everybody the way you want it to work for you it is a lost cause. Even if the browsers consistently supported the behavior you apparently seek, a large number of people would install plugins for the explicit purpose of disabling your ability to do that to their browser. Very few users have any interest in a non-tabbed browser, and will be very impatient with any app that tries to demand it. By attempting to demand it your app will consistently close the pages people have open for other reasons. Personally I used a parent container to effectively get tabbed browsing before browsers started supporting it, initially with Maxthon. Even if you got it to work flawlessly in all browsers the way you want very few people would tolerate it.
You basically have two choices. Work from the perspective of a tabbed browser user, and use a plugin to redirect all tabs into a single tab on your own browser. If no FF addon suites you modifying "
Close other tabs" to auto close inactive tabs, setting activate new tabs to true, and don't show tabs on last tab to true will get you a tabless FF that operates in a consistent manner with a tabed browser. That addon can also be implemented as a very simple UserJs without the overhead of an addon.
First option (Not ideal):
With the above configuration merely open the help file in a new tab, consistent with the expectations of a tabbed browser. You personal browser will then automatically close the existing tab, or better redirect the existing tab to the new tab location, leaving no tabs for you to deal with. Your app then doesn't need to deal with these issues, the browser does the work for you. Then when exiting your app leave the browser open. It's the ONLY way to be consistent with tabbed and non-tabbed users, and more importantly does not kill
everything else a tabbed browser is doing unrelated to your app. Attempting to make my browser operate in a manner consistent with someone else's expectations will
never be allowed, no matter how complex a UserJS, sandbox, wrapper, redirect, whatever I have to create to prevent it.
Second option (Best option):
Switch from using <unknown> browser to using hh.exe. This provides consistency across all windows. You can then simply use DDE to redirect the page hh.exe is displaying. Or, not so good, you can simply kill the previous instance of hh.exe you created and open another, just like you are attempting to do with <unknown> browsers. Personally, so long as the app closes anything at all, other than itself, it will never find a use on my machine. Having a config file or command line switches to turn the killing of previous instances or pages on and off is also a viable option.
Questions:
So how do you expect it to actually work for you, and how does that differ from what you are trying to impose on others? Are you mistaken your attempt at getting browsers to cooperate with an attempt to force everybody's browser to be what you want in your browser? A question that needs carefully thought through before any effective GUI development even makes sense. The fact that browser developers woke up to the fact of these inconsistencies in peoples preferences is the source of your present headache. Never force preferences on people, rather do what you need to do to your own browser to consistently get the behavior you want locally. It's not the job of your external app, nor possible, to force your browser preferences on others.
