locked
How to trap F1 (help) when "Tools -> Options" is active RRS feed

  • 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++)

    Thursday, December 18, 2014 7:25 PM

All replies

  • Sunday, December 21, 2014 2:42 AM
  • Thanks very much. I'll look into this and hopefully it will lead me to a solution, even though it's based on add-in technology (I need a solution for a VSPackage). Honestly though, I'm thoroughly bewildered by MSFT. In recent years they've been making decisions leading to no end of grief for many developers. From the elimination of installation projects in VS, only to later bring them back after thousands of complaints (as a separately installed package), to the elimination of add-ins in VS2015, this is not progress. It's regressive, frustrating and very expensive. I have a working (commercial) add-in that's not going to work in VS2015 because MSFT is making add-ins obsolete, and am being forced to convert it to a VSPackage with no noticeable benefit whatsoever to my customers. It's the same app, but with no choice in the matter, I've now spent weeks refactoring my application to work as a VSPackage and I can't find a simple way to trap F1 in "Tools -> Options". This is doable in add-ins as mentioned in my opening post, so I can't understand why it seems to have been removed entirely in VSPackages. It's such a fundamental requirement, yet there seems to be no documented way to do it, as I've been up and down the Internet trying to figure out how. And now, based on the link you posted, I'm forced to rely on a stackoverflow response, apparently from a former MSFT employee who wrote the F1 specification for VS2005 (but whose response, in his own words, is "likely out of date"). While I do appreciate this link since maybe I can leverage it to do what I need to do (I'm doubtful though), I'd like to know where the official way to do it is? Where is MSFT's documentation for this. It's incredulous that with 2015 just around the corner, programmers should have to be dealing with this nonsense. This isn't directed at you of course (again, your response is appreciated), but whoever's pulling the strings at MSFT. Is anyone there listening?

    Larry (25+ years on MSFT platforms, mostly in C/C++)

    Sunday, December 21, 2014 5:05 PM
  • Hi Larry,

    The underlying DialogPage class typically used to implement Tools.Options pages, doesn't have any way to hook that F1 key. Most packages integrate their F1 help via MSHelp 2.0 content, and this page simply uses the registry pathing to generate a F1 keyword that is then used to query the merged documentation.

    I think you may be able to work around this by implementing your options page by implementing IPropertyPage, which would allow you to get the Help call, but the only instances where I've seen this done, is with project property pages, and not with tools.options pages.

    I've got a test package started with some experiments to see if I can get this working. Will post back here as soon as I have the results.

    Sincerely,


    Ed Dore

    Thursday, January 1, 2015 12:12 AM
  • 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++)

    Thursday, January 1, 2015 5:35 PM
  • Hi Ed,

    Any news on your end. Implementing "IPropertyPage" had no effect though it's unclear if there's anything special I need to do. It's starting to look like I'm facing two ugly choices, either remove my program's options from "Tools -> Options" entirely and have users launch it some other way, or leave it as-is but display a message somewhere that F1 no longer works unless users explicitly tab over from VS's tree control on the left to my "DialogPage" on the right (where F1 will then work again since my "DialogPage" has focus and can trap it). The 3rd option of integrating my help into VS itself isn't something I can do (again, because my existing ".chm" file is also used by an external app outside of VS including on machines where VS may not be installed). And the 4th option of trapping F1 either by changing VS's key bindings and/or using some system-wide hook is also very messy business (and therefore not something I'm going to consider). Honestly Ed, I know it's not your fault personally but I've been spinning my wheels for weeks now on this issue and it's all very frustrating (F1 can no longer be trapped in "Tools -> Options"? Come on!!!)

    Wednesday, January 7, 2015 1:06 PM
  • Hi Larry,

    When confronted by issues like these, I typically suggest reporting this by opening a paid support incident when you need a fast turnaround. Most of the MS folks (like myself) only hit these forums when we've got some spare time to play with.

    That being said, I did a detailed analysis of the codebase in question, and can say without hesitation that we screwed up here. I've explored every code path involved, and there's just no way to override what the shell is doing here. At least that's the current state of affairs.

    Each options page is represented internally by a CVsPropPage class, which has a m_bstrHelpKeyword member. This is just an LPOLECSTR that contains the help key we push to the help system. The problem is that we don't push the PSN_Help notification to the page, when this member is set. It's only when this isn't set that we attempt to pass the PSN_Help notification down to the page or invoke IDTToolsOptions::OnHelp.

    When the CVsPropPage is initialized for package based option pages, we always set the m_bstrHelpKeyword string based upon it's location in the registry hive. After poking around this most of today, I'm certain there's no way to change this behavior, without a design change here.

    Ultimately, this appears to be an oversight on the part of the IDE team. We've never seen a request to launch or intercept the help request on package based tools.options pages to launch a .CHM before. And with the removal of the Addin/IDTToolsOptions for vNext, we've got a hole here.

    I'll get a bug submitted to the IDE team to see if we can get this addressed somehow. I'm thinking we should change up how the PSN_Help is processed in the dialog's underlying dialogproc. We'll likely have to cover both the winform and wpf scenarios here, so it's not quite as simple as just pushing the PSN_HELP notification to the page (WPF based pages don't have a WndProc, so we don't have a way to receiving notifications like that, which means well need to come up with an interface based solution here).

    Sincerely,


    Ed Dore

    Wednesday, January 7, 2015 10:06 PM
  • Hi Ed,

    Ok, understood. I sent a message to your published email address to wind things up (no longer relevant in this forum). Thanks again for all your help. Appreciated.


    Larry (25+ years on MSFT platforms, mostly in C/C++)

    Thursday, January 8, 2015 1:29 PM