Hi,
This is "hands down" the best help forum I have ever used. I really appreciate your time and effort in responding to my questions.
Do you have any thoughts on how to distribute or handle forms in a policy and procedure manual environment?
What I have been doing is designing a form in work, excel or publisher and then turning it into a bit map to be printed out of the .chm program.
I have found the following disadvantages
The print size seems to be limited to 640x840 pixels to print out on one page on most (some its still to large) of the printers around here.
The print quality of a bitmap out of windows help is poor.
Because the form is a bit map, any change I need to make envolves a significant amount of work in at least 3 programs.
If I use the Execfile macro and open forms in their native programs and then print. This would have several advantages:
The form could be larger
The print quality would be much higher then the bitmaps.
I could create "fill in" forms so that user supplied information could be inputed directly and then printed.
Changes could be made and distributed in one file and none of the links need changed in H&M or windows help.
On the other hand the disadvantages are adding another program for the user to know and a number of additional steps to a finished, printed form. Training someone to print out of microsoft publisher is a much more daunting task then pressing one button in the help program.
I would appreciate hearing how you have handled these issues.
Thanks
Distributing and printing paper forms using execfile: macro
Moderators: Alexander Halser, Tim Green
-
- Posts: 338
- Joined: Tue Sep 17, 2002 1:32 am
- Location: Australia
- Tim Green
- Site Admin
- Posts: 23183
- Joined: Mon Jun 24, 2002 9:11 am
- Location: Bruehl, Germany
- Contact:
I can think of two other alternatives:
1: Inline HTML
If you use inline HTML (Insert / Plain HTML Code...) you could create interactive forms and complex XML forms using Dreamweaver or Front Page or any other advanced HTML editor and slot them into your help project. The advantage of this is that you can open them directly in the HTML Help viewer, because it natively supports HTML.
2: Links to online forms
This is actually an extension of the first option. If you create HTML/XML forms and serve them from a central location on your intranet or even the Internet you then just need to link to them in your HTML Help project, where you can again open them in the viewer or separate windows, as you please. The huge advantage of this is that you can update your forms whenever you like without redistributing your help package. There's also nothing to prevent you from linking to PDF forms on the intranet or Internet, if you prefer that format and don't need to make the forms interactive.
1: Inline HTML
If you use inline HTML (Insert / Plain HTML Code...) you could create interactive forms and complex XML forms using Dreamweaver or Front Page or any other advanced HTML editor and slot them into your help project. The advantage of this is that you can open them directly in the HTML Help viewer, because it natively supports HTML.
2: Links to online forms
This is actually an extension of the first option. If you create HTML/XML forms and serve them from a central location on your intranet or even the Internet you then just need to link to them in your HTML Help project, where you can again open them in the viewer or separate windows, as you please. The huge advantage of this is that you can update your forms whenever you like without redistributing your help package. There's also nothing to prevent you from linking to PDF forms on the intranet or Internet, if you prefer that format and don't need to make the forms interactive.
Regards,
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.