再提：关于帮助系统的开发(200分)

  • 主题发起人 主题发起人 龙丹
  • 开始时间 开始时间
龙

龙丹

Unregistered / Unconfirmed
GUEST, unregistred user!
1. 各位富翁们开发的程序到底做不做帮助系统？是程序员自己做还是由专人来做？
2. CHM格式的帮助文件，能否实现上下文敏感的功能？
3. 帮助文件与程序的事后关联有多大意义，或者说你希望如此吗？
4. HelpScribble 6 有没有破解版？
我以前只做.HLP格式的帮助文件，帮助系统的开发不是程序员，帮助文件与程序事后
关联，帮助系统的开发需要付出昂贵的代价，到底有多大实用价值却难以评估，这可
能很大程度上取决于帮助文件的内容。
 
还是需要一个帮助系统，对用户负责。
用chm格式更好，使用耶書制造CHMmaker（国产）制作很方便，搜一下下载和说明内容很多。
 
用Visual CHM也不错
 
对于 chm 格式，推荐的富翁不少，我所关心的是能否实现上下文敏感的功能，如何实现
 
1 帮助肯定要做，是我自己写的
2 CHm的格式开发工具不少，也挺方便的，上下文敏感，我也关注
3 一个产品没有帮助是不完善的，肯定要消耗工作量的，要不呢卖出去了，还要整天打电话问
你怎么操作不成？
 
关注！
 
我这里帮助是别人做的,不是自已　做
 
"上下文敏感"是不是哪用哪调出？好多这方面的问题
http://www.delphibbs.com/delphibbs/dispq.asp?lid=1125823
你找找看。
 
对于系统内各模块的帮助最好由对应开发人员自己写，他们清楚程序运行的每个流程和具体环节
最后需要一个专人将大家所有帮助资料结合成一个帮助文件，然后再通知各开发人员将帮助加到
系统中
CHM格式文件可以实现上下文敏感，需要建立索引链接，用HTML Help Workshop制作帮助文件也
很好
一个系统如果没有帮助文件，那么将会给开发人员在培训用户使用系统的工作量增大，造成一些
不必要的人力资源浪费
 
对于帮助文件，我认为最重要的有两点：一是内容，二是上下文敏感。
如果一个帮助文件中只有类似按什么键执行什么功能一类的内容，这种帮助要不要都无所谓，
用户用上几次你的程序就都知道了，然后你的帮助文件就成了垃圾；但如果你的程序出错了，
用户可以通过F1就可以获知如何处理或善后，那这就是最具价值的内容。
没有上下文敏感帮助根本就算不上是联机帮助，那只是某种格式的说明书而已。
帮助主题与功能控件关联是实现上下文敏感所必须的，在Delphi中通过填写控件的HelpContext或
HelpKeyword来实现，程序员在做界面时就要填写帮助文号，但通常在这时候还不知道HC是多少，
这意味着要等帮助文件做好以后获得一个HC清单，然后再进入Delphi慢慢去填写，再重新编译。
各位富翁是没有做过这工作，还是觉得这样干很有趣，抑或是采用了什么其它的办法？
我以前做过一个HCMarker，将HC直接填写到EXE／DLL／DFM中去，但现在又可以用HelpKeyword了，
关键是我的帮助开发人员想采用HCM格式，但我不知道这些信息能不能直接应用在CHM上？
请继续讨论。
 
>>对于帮助文件，我认为最重要的有两点：一是内容，二是上下文敏感。
不一定非要用.CHM和什么.HLP格式
简单的一个方法供参考：
放到数据库中 用户要用时 从库中调出相应的主题即可实现上下文敏感。
控制起来又灵活~~~
 
[green]{>>对于帮助文件，我认为最重要的有两点：一是内容，二是上下文敏感。
不一定非要用.CHM和什么.HLP格式
简单的一个方法供参考：
放到数据库中 用户要用时 从库中调出相应的主题即可实现上下文敏感。
控制起来又灵活}[/green]
to dingbaosheng:
如果用户只想看帮助，却不得不启动程序和数据库服务器。
对于大多数的MIS系统，我想用户应该对业务流程比较熟悉，那么帮助就不需要太多的说明
业务流程，只需要说明操作过程和注意事项。
to 龙丹先生
说帮助的编写很昂贵，除非是如微软的office等，我想一般的帮助编写虽然也需要
投入一定的人力，但不至于很昂贵吧，如果真是这样，可能说明项目开发中文档编写不是很
好，事实上，从详细设计文档就可以得到大部分的最终帮助文档内容，事实上只是转换格式
、补充说明和挂上程序。
 
上下文敏感可以搞定，你可以搜索这样一个单元，htmlhlp.pas
http://delphibbs.com/delphibbs/dispq.asp?lid=1139819
 
若要做出用户真正喜欢使用的帮助文件，其投入可能比编码要高。
设计文件是面向开发人员的，帮助文件是面向应用人员的，从设计文件导出的帮助文件恐怕
不是用户所希望的。
我以为，帮助系统开发人员最初根本就不应该了解你的设计，而是站在用户的角度来使用软
件，记下所有的疑惑，然后再看设计文件，与程序员交流，最后组织素材，编撰成文。
 
用FrontPage做好帮助文件的HTML文件，并在HTML文件中设置上下文的超级链，用
HTML Help WorkShop编译HTML文件，可实现上下文敏感的功能。
 
在我原来的单位，是写的程序的程序员自己写帮助，hlp格式的，上下文敏感。
现在的单位，是每个项目组专门有一个人负责写文档，html格式和hlp格式都有，
做的很完善，也很漂亮，因为是MM做的。
 
有没有人用 HelpScribble 啊？
 
我的帮助一律用html格式，方便快捷，用word就行了：）
 
如果程序专业性较强，用户经常要用到帮助（比如Delphi），那么最好用.hlp。
如果程序较易操作、强调个性，用户不太用得上帮助，那么最好用.html。
如果程序极易操作且为绿色软件，那么可以不用帮助，或用Messagebox/Edit/Text。
 
您必须登录或注册才可回复。

Similar threads

Ray
[转]终于可以发布Delphi下收点OSGI精髓皮毛而设计的插件框架WisdomPluginFramework
回复
4
查看
4K
chlkuei
C
D
各位大虾请帮忙，关于帮助文件的问题！急(50分)
回复
4
查看
164
doolii
D
S
打开*.HLP时的奇怪提示(100分)
回复
3
查看
123
swhgoon
S
G
怎么做.chm 的帮助文件？(50分)
回复
6
查看
142
smallsun007
S
H
请问:怎样修改 WINDOWS 的系统图标(开始菜单中的) ?(100分)
回复
6
查看
171
hhb1981
H
后退
顶部