How to trap F1 (help) when "Tools - Options" is active

Question

Hi there. I already posted this question previously with no appropriate response. I wouldn't normally post it again but I'm justifiably losing my patience. I can find no way to trap F1 (help) when someone activates my program's options via "Tools
-> Options". This is supported in add-ins via "EnvDTE.IDTToolsOptionsPage.OnHelp()" but after spending countless hours hunting for how to do this in a VSPackage (spinning my wheels for days now), I have yet to find an answer. Would someone
from MSFT care to enlighten me on how to pull this off. I simply need to intercept F1 so I can launch a ".chm" file when my options are showing under "Tools -> Options". Thank you.
Larry (25+ years on MSFT platforms, mostly in C/C++)

Answer 1

Hi Ed,
Thanks very much for your response. I'll look into this and hopefully there's something that can be done. Am anxiously looking forward to your own results as well. I have looked into other possibilities however, like overriding "DialogPage.OnActivate()"
and trying to set the focus to my options page, where I then have control (so trapping F1 would be easy). This isn't doable either though based on my testing. Changing the bindings to intercept "Help.F1Help" is also fraught with problems. Both these
ideas are hacks though, as would be trying to get underneath Visual Studio to trap F1 before it even gets control. Integrating my help into MSHelp isn't something I want to do either, not just because of the work involved, but because of the nature of my app.
My ".chm" file contains the help for my add-in (now VSPackage) as well as a standalone ".exe" that goes with it (which is run independently of VS). A single ".chm" file therefore serves both programs so two help systems isn't
viable. Note that even though add-ins will soon be obsolete, I honestly find it bewildering that MSFT would force developers to use their help system given that add-ins supported "EnvDTE.IDTToolsOptionsPage.OnHelp()". There should be an analogue
for this in a VSPackage since it's so basic. There's enough work involved having to convert an add-in to a VSPackage while still supporting older versions of VS (many programmers now have to deal with both depending on the version), but the fact that a VSPackage
doesn't even seem to support everything an add-in did (F1 in this case), means that MSFT has created difficult and expensive problems for many developers. This isn't directed at you of course (your help is certainly welcome and greatly appreciated), but I'm
at a loss to understand the business rationale for this. It may be easier for MSFT to deal with one system only now (VSPackages instead of add-ins), but it hurts many of its existing customers who have to deal with the fallout of this decision And honestly,
I see no immediate advantage to VSPackages over add-ins. Like so many other technologies before it, it's just a different way to do the same thing (both have their pros and cons). I'm not here to rant though, but it's just the frustration of having to spend
weeks on this one issue alone, in addition to all the other work required to convert an add-in to a VSPackage. I've had a stable, working add-in for years now and am being forced to convert it to a VSPackage with all the ensuing problems (time, expense, need
to support both technologies now, add-ins and VSPackages, as well as unknown future problems, etc). At the end of the day though, my customers will see no difference in the program. So what was the point of going through this exercise. I (and many others no
doubt) are going through this grief only because MSFT has given us no choice.
Larry (25+ years on MSFT platforms, mostly in C/C++)