Kirill K. Smirnov wrote:
Eric, there is a mess in winhelp and winhlp32 in "Context" and "Topic" concept: what winhelp calls "topic", winhlp32 calls "context", and what winhelp calls "Context" winhlp32 calls "Topic without CNT section". So, the buttons are messed too.
I suspect there are other "features".
We couldn't implement winhlp32 and winhelp in one box.
well, this still could be possible, even if it's a bit more complex to handle IMO, the differences are, in most of the cases, cosmetics (name of buttons, positions of menu), but also in MS way, new features only in winhlp32 so I was calling for a unified tool that would be doing what the two original programs were doing, even if the user interface doesn't match everything perfectly
I suggest to at least get rid of old winhelp interface in favor of winhlp32, and create symlink winhelp->winhlp32 in windows directory. Does it save the day?
IMO, we don't need two apps but we could make most apps believe both winhelp & winhlp32 are present and put all effort into a single application we should also reimplement winhelp based on richedit for the rendering A+
richedit sound very good - select/copy very easy! (but riched32 is not complete yet)
yes, but we would kill two birds with one stone: - winhelp/winhlp32 requests a good rtf renderer (lots of layout stuff is still missing from winhelp), so this needs some work - richedit is a rtf renderer/editor so it's easier to add the missing stuff to richedit rather than reinventing the wheel in winhelp
A+