标签: context-sensitive-help

我在SuperUser中为用户的观点添加了这个问题.

所以我用Delphi或.NET创建了一个可以在桌面系统上运行的应用程序.一些不错的GUI,具有各种功能和不错的功能.它运行良好,测试告诉我它几乎没有错误,我即将部署它...

等待!它需要一个帮助文件,因此用户可以从应用程序中调用上下文相关的帮助!

或不？这些天帮助文件真的是桌面应用程序的必需品吗？他们是否真的需要对语境敏感,握着用户的手,告诉他们必须在这个标有"出生日"的字段中填写他们的出生日期？或者帮助文件变得有点过时了？

这是我想知道的事情,这有点主观,所以相反,我会向开发桌面应用程序的所有人提出不同的问题:你(仍然)提供上下文敏感的帮助文件吗？

是的,或者不,请.随意添加一些主观文本,但对我而言,重要的是了解现代开发人员是否仍在为其GUI应用程序添加上下文相关帮助.

(顺便说一句,我自己已经转移到非上下文PDF文件,可以手动打印.维护起来要容易得多.)

这个问题说的都是真的.如果您正在编写WPF应用程序,那么如何集成应用程序帮助？2013年中期的比赛状态如何？

从搜索引擎的下午开始,似乎没有明确的答案,但有几种选择:

1. 编写自己喜欢的基于工具提示的帮助(但是从哪里获取数据？)

2. 使用.CHM文件和Windows窗体帮助系统(对我来说似乎很古老).

3. 使用Microsoft Help Viewer 1.X或Microsoft Help 2.0.

   • 关于MS最近/批准哪些内容存在一些混淆.看起来帮助查看器1.X可能是Microsoft Help 2.0的推荐选项.这些名字如此相似并没有帮助......
   • 2.0的状态是什么？我们应该使用它吗？是否曾全面部署？

4. 使用第三方产品编写您的帮助文件并以某种方式链接到它们 - DocToHelp/NetHelp,NetAdvantage在线帮助等...

此外,您使用什么基于XAML的标记/属性来提供必要的上下文？推荐的方法是什么？

令人惊讶的是,在WPF中支持基于应用程序的帮助没有明确的途径.

我们目前有许多桌面应用程序(PowerBuilder,Winforms,WPF),它们使用单​​个CHM来提供上下文相关帮助.我们希望摆脱CHM,因为它很难维护,但我们找不到合适的替代方案.理想情况下,我们希望我们的开发人员可以继续帮助文件是最新的(也许在一个wiki),因为它们增加功能,并且只需导出此为PDF或类似的东西,但它是可以使用PDF的上下文敏感的帮助,或CHM还有其他有前景的替代方案吗？

这是这个问题的延续.我有一个文件,我想要包含我的安装包(.CHM帮助文件),我需要在安装过程中从代码访问.它不需要安装到用户的机器上.所以我想
- 将文件包含在安装包中,可能是未压缩的(所以我想我会用[Files] ... external标志来做).
- 在安装过程中使用以下代码引用文件:

procedure HelpButtonOnClick (Sender: TObject) ;   
var
    ErrorCode : Integer ;

begin
ShellExecAsOriginalUser ('open', ExpandConstant ('{???}') +  '\MyHelp.chm', '', '', SW_SHOWNORMAL, ewNoWait, ErrorCode);
end ;

那么我可以在安装开始之前引用该文件 - 即在将任何文件复制到用户机器之前吗？如何指定ExpandConstant ('{???}')文件的路径？我在向导表单上有一个调用上面的处理程序的帮助按钮.

我正在为在 Visual Studio .NET 中构建的现有 WinForms 应用程序实现上下文相关帮助。我HelpProvider在表单中添加了 a并将HelpNamespace属性设置为一个美妙的.chm，涵盖表单上的每个控件和菜单项。我已经设置了HelpKeyword所有衍生自的必要控件，Control到目前为止一切都很好：F1 完美运行。

我的问题是我不知道如何为菜单项做到这一点。它们使用ToolStripMenuItem类，该类不派生自Control，因此没有HelpKeyword属性。我应该如何为单个菜单项提供上下文相关的帮助？谷歌先生一直不太热情。