home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / mswindo / programm / tools / 704 < prev    next >
Encoding:
Text File  |  1992-08-13  |  3.7 KB  |  78 lines

  1. Newsgroups: comp.os.ms-windows.programmer.tools
  2. Path: sparky!uunet!haven.umd.edu!decuac!pa.dec.com!nntpd2.cxo.dec.com!nntpd.lkg.dec.com!e2big.mko.dec.com!engage.pko.dec.com!tfh.enet.dec.com!marshall
  3. From: marshall@tfh.enet.dec.com (Hunting the Snark)
  4. Subject: Re: Help engine replacement for WINHELP.EXE
  5. Message-ID: <1992Aug11.195907.12899@engage.pko.dec.com>
  6. Sender: newsdaemon@engage.pko.dec.com (USENET News Daemon)
  7. Organization: Digital Equipment Corporation
  8. Date: Tue, 11 Aug 1992 20:36:41 GMT
  9. Lines: 67
  10.  
  11.  
  12. In article <ys2mf4l.garyd@netcom.com>, garyd@netcom.com (Gary Dietz) writes...
  13. >In article <z21mc6m.ergo@netcom.com> ergo@netcom.com (Isaac Rabinovitch) writes:
  14. >>In <w1ym8xa.garyd@netcom.com> garyd@netcom.com (Gary Dietz) writes:
  15. >>>> Why not just use WINHELP?
  16. >>>Well, quite frankly, the windows help viewer sucks.
  17. >>I more or less agree, but I disagree with some of your specifics.
  18. >>>Some simple examples:
  19. >>>- You can't do a full-text search
  20. >>HLP files are compressed, so a full-text search would be *very* slow.
  21. >>And fancy searching tools (which, come to think of it, are the main
  22. >I don't want to search *existing* help files.  In fact, I could care less
  23. >about exsiting help files.  I want to create a help file for OUR product
  24. >and distribute a viewer for it WITH our product.
  25.  
  26. The point is still true though that a full text search would be very slow.
  27. My opinion is that you'd be better offer spending the time to develop a good 
  28. set of keywords and cross references.
  29.  
  30. >>>- The placement of bitmaps is very rudimentary
  31. >>I'm no sure what you mean.  In any case, you might want to check out
  32. >>the new bitmap tools for the 3.1 help compiler.
  33. >I can place a bitmap on the left, on the right, or in the center.  I think
  34. >that there is a sort of way to get text to flow around a bitmap, but I can't
  35. >get it to work.
  36.  
  37. in WORD, placing the bitmap using {bml foo.bmp} will put the bitmap foo at the
  38. left edge of the paragraph and wrap the text next to it. {bmr ...} does the 
  39. same for the right edge. {bmc ...} treats the bitmap as a character, that is it
  40. is paced in the center and will end up wherever the word wrap takes it. 
  41. This works just fine. In 3.0 on the bmc could be a hot spot, in 3.1 all three
  42. can be.
  43.  
  44. >>>- I can't dictate what fonts the viewer will use unless I assume the
  45. >>>  default fonts that ship with windows
  46. >>This is a problem with *all* Windows apps.  If you know how force a
  47. >>program to use a font that isn't actually installed on the user's
  48. >>system, I wish you'd share it with us!
  49. >I am not a windows programmer (I don't even play one on TV).  I am just 
  50. >a technical writer with an attitude problem.
  51. >So, basically, I understand that you CAN'T do this.  DOesn't stop me from
  52. >wanting to do it though.   :-)
  53.  
  54. Well, there is the FORCEFONT option in the .HPJ file to force HELP to use 
  55. the particular font you specify. Don't know what happens if the end user
  56. doesn't have it installed though. But I suppose you could ship that font with
  57. your application just to make sure.
  58.  
  59. >Again, I don't care about backward compat.  I don't want to view 
  60. >*existing* HLP files.  I want to compile my own and suppy them to our
  61. >customers with a viewer.
  62.  
  63. And I still think you'd be alot better off working with WINHELP than developing
  64. something completely different. So WINHELP is not ideal, its not totally
  65. useless, and it is what a Windows user is used to.
  66.  
  67. I've been looking through TPW's on-line help and there is (to me) an amazing
  68. amount of information in there about developing Help files. Infinitely more
  69. than the chicken scratch supplied in the MS-SDK. There is also indication of
  70. alot of capabillity that wasn't even hinted at elsewhere. 
  71.  
  72.  
  73. Sm (neophyte windows programmer, 1 app under my belt)
  74.