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.
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)
-- Kirill K. Smirnov
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+
On 02.11.2006 22:04, Eric Pouech wrote:
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
FWIW, winhelp.exe is a 16-bit executable in Win XP. If I had to guess why, I'd say it's for compatibility: iirc you can call DLL functions from help files; so the 16-bit winhelp is kept to allow 16-bit .hlp files using DLLs to continue to work.
-f.r.
On 02.11.2006 22:04, Eric Pouech wrote:
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
FWIW, winhelp.exe is a 16-bit executable in Win XP. If I had to guess why, I'd say it's for compatibility: iirc you can call DLL functions from help files; so the 16-bit winhelp is kept to allow 16-bit .hlp files using DLLs to continue to work.
-f.r.
-
Eric Pouech -
Frank Richter -
Kirill K. Smirnov