I wondered if some can advise me as to how to make help files and linking them in to the dabase. i.e. if someone clicked on a certain section for help then it would go to the help for that section. Is there an easy program to help write the files??
Creating help files
- Thread starter bunji
- Start date
You could create a form in your db and type in all of the information that you want to present. Then call this form in the onclick event of a command button.
In my circumstance, I have a FE BE situation using a server. I made my help section in the form of a web page located on the server. When the user clicks the button it opens the HTML document in a browser. In this way, I do not have to generate a new .mde if I need to make changes to the help sections. I simply edit the web page and its done.
In my circumstance, I have a FE BE situation using a server. I made my help section in the form of a web page located on the server. When the user clicks the button it opens the HTML document in a browser. In this way, I do not have to generate a new .mde if I need to make changes to the help sections. I simply edit the web page and its done.
boblarson
Smeghead
- Local time
- Yesterday, 19:38
- Joined
- Jan 12, 2001
- Messages
- 32,059
There is an easy program to create help files. I like, and use, HelpScribble (you can get it at http://www.helpscribble.com/ ).
The nice thing about it is that you can try it, almost fully functioning (there's only a couple of features that you can't use, but I don't remember what they are.), before you buy it ($99).
To use help files in HelpScribble, you create the help file and assign topic numbers (it does it automatically) and then after it compiles the help file, you just reference the location in your forms, in the help file property, and in the places you want to be able to do context-sensitive help, you put the topic numbers in the help context property. Then, when you are on a certain form, or in a certain field and click F1, your topic will appear.
The nice thing about it is that you can try it, almost fully functioning (there's only a couple of features that you can't use, but I don't remember what they are.), before you buy it ($99).
To use help files in HelpScribble, you create the help file and assign topic numbers (it does it automatically) and then after it compiles the help file, you just reference the location in your forms, in the help file property, and in the places you want to be able to do context-sensitive help, you put the topic numbers in the help context property. Then, when you are on a certain form, or in a certain field and click F1, your topic will appear.
- Local time
- Yesterday, 21:38
- Joined
- Feb 28, 2001
- Messages
- 30,167
Now, this isn't for everyone, but I once had occasion to try a different approach. It was a pain in the toches but it worked.
I had an unbound text box labeled "Hints" and left it blank in the form. BUT every control, when you tabbed or clicked into it, fired off a "GotFocus" routine to fill in the Hints textbox with a sentence or two describing the purpose, function, units, etc. for the selected control. There is such a thing as the FORM getting focus without giving focus to one of the controls, so there was a Form_GotFocus "hint" too, telling the user the overall purpose of the form.
Now, it was tedious, but my users LOVED it. And it was so easy to do. I also played games with the label associated with the fields on GotFocus and LostFocus events, changing the label color from black to something like bright purple, changing the background color for text boxes, stuff like that. The LostFocus event for each control tested whether the control's .VALUE and .OLDVALUE were the same and changed the color scheme of the controls if they were not. Pale pink backcolor and solid red forecolor, if I recall correctly. That way the users knew what they had changed. That, of course, required a Form_OnCurrent event to reset all forecolors and backcolors, but that was a trivial process.
Anyway, since I had the GotFocus and LostFocus routines to manage control colors, it was a no-brainer to add lines to maintain the hints area. While it wasn't quite a cut-n-paste enterprise, it went pretty fast to implement it.
I had an unbound text box labeled "Hints" and left it blank in the form. BUT every control, when you tabbed or clicked into it, fired off a "GotFocus" routine to fill in the Hints textbox with a sentence or two describing the purpose, function, units, etc. for the selected control. There is such a thing as the FORM getting focus without giving focus to one of the controls, so there was a Form_GotFocus "hint" too, telling the user the overall purpose of the form.
Now, it was tedious, but my users LOVED it. And it was so easy to do. I also played games with the label associated with the fields on GotFocus and LostFocus events, changing the label color from black to something like bright purple, changing the background color for text boxes, stuff like that. The LostFocus event for each control tested whether the control's .VALUE and .OLDVALUE were the same and changed the color scheme of the controls if they were not. Pale pink backcolor and solid red forecolor, if I recall correctly. That way the users knew what they had changed. That, of course, required a Form_OnCurrent event to reset all forecolors and backcolors, but that was a trivial process.
Anyway, since I had the GotFocus and LostFocus routines to manage control colors, it was a no-brainer to add lines to maintain the hints area. While it wasn't quite a cut-n-paste enterprise, it went pretty fast to implement it.
Similar threads
