MMHelp Form Templates customisation/control

[Bryan Skellern]

I use the SimpleViewer(noTOC).dfm for product information CDs however I would like more control over their size, location & appearance of the template. Specifically to get rid of the blank margin between the image & dialog borders.

Much of Help & Manuals user base utilises Delphi (for their applications development) and has a programming background. It would be invaluable to know more about this TFameViewer class and how it can be controlled and also know how custom templates could be developed.

[Alexander Halser]

The skins are Delphi forms, as you already discovered. They are saved
in binary format (not text) because the viewer is compiler with Delphi 3 and
does not understand the text format. Delphi 3 creates much smaller exe files
than the recent versions, that's the reason.

I doubt that most of our users are Delphi programmers, so if only Delphi
programmers can edit the templates, this feature would be very limited. One
of the reasons why we did not publish an editor for the skins (let alone the
fact that it has to be written in Delphi 3, aaargh!) is that you cannot cut
back features once you have them implemented. New templates with new
features for the MMH output format are on the wish list, but a designer is
not. Not yet. Would be the wrong direction.

The MMH format would be a perfect help system for Delphi cross-platform
development, for Windows and Linux. Please take me right: I am talking about
a draft what the future may bring - this is nothing we are already
working on. We will have a long way to go and not all tools and components
are available yet. But the idea behind reads this way:

• The MMH viewer could be available as open source, both in executable form
and dynamic link library

• Viewer and data could be combined (stand-alone exe) or separated

• The data package should use a common compression format, such as ZIP or TAR,
whatever is appropriate for the target platform (Windows/Linux)

• Password protection could work on file or chapter basis, using the
standard protection mechanism of the archive format. Copy protection
won't be possible.

• The entire format could be documented and - given that the project is
open source - be a widely accepted help format at least for Linux (I'm
dreaming... )

• So Help & Manual would be just one of the tools which creates this format,
not the only one. Third parties could write their own IDE to edit the
configuration files, skins and HTML pages. I particularly like the idea of
having some competition in this field


So far the idea behind. We all do not know where the IT landscape goes
to. Whether Linux will become an established end user platform like Windows
or if .NET will rule the world. First movers have a hard stand. We don't want
to be the very first mover in this field. But it's fine to be prepared for
whatever comes along.


The TFrameViewer, by the way, is the HTML viewer from David Baldwin
(http://www.pbear.com), other unknown components in the skins are
a THMPanel (a basic TPanel) and the page control class
THMPagecontrol. The latter is a black box that contains the
navigation functionality. In general, the viewer identifies controls by
names. The HTML view must be named VIEW, the back button must be named
GOBACK. Control hints follow the same rule: they are replaced at run
time with localized language strings. The hardcoded hint is the ID of
the language string.