TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:RE: F1 for help From:Mark Magennis <markmagennis -at- yahoo -dot- com> To:TECHWR-L <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 22 Mar 2000 04:25:25 -0800 (PST)
Jim Shaeffer wrote:
> Microsoft says:
> F1 Display contextual Help window
> SHIFT+F1 Activate context-sensitive Help mode (What's This?)
> From _The Windows User Experience_, under Common Shortcut Keys.
This is good information but it is unfortunately not as easy as this
in the real world for three reasons:
- Changes to the features offered by WinHelp over the years.
- Microsoft's inability to offer "correct" or even standard
functionality between two of their major programming languages -
Visual C++ and Visual Basic - which are used to write many
- Differences of opinion between WinHelp developers concerning what
type of help is most helpful.
I believe "Clippy", that annoying little *!! -at- ! that pops up with
irrelevant and unwanted suggestions, is restricted to Microsoft
Office and if you are developing your own application you cannot use
The following explanation of the history and current state of F1
functionality should prove informative. Note that it was not written
by myself and I can't remember where I got it from, otherwise I would
cite the author.
<Someone else's explanation>
Before Windows95, the F1 key was usually used to call window or
dialog based help, perhaps because that was the lowest level of Help
that was created.
Some applications offered field-level help as well. You pressed
Shift+F1 to get the help pointer and then clicked on a component
(field) to get help. You pressed F1 for dialog-level help. Other apps
made field-level help available through F1 by displaying field-level
help for the control with focus.
Win 95 put the the ? button in the title bar, which is the functional
equivalent of Shift+F1. At the same time, a lot of applications
started providing only field-level help. Thus, it made sense for F1
to display field-level help for the control with focus because there
was no dialog-level help. Yet, apps that offered both field-level and
dialog-level help still had to make a decision: Shift+F1 or ? button
for field-level, F1 or Help button for dialog-level. Or some
combination Unfortunately, there is now neither a solid tradition nor
a de facto standard.
The matter is further complicated by the differences in the default
behaviour of different programming languages, e.g. Visual Basic and
Visual C++. In most cases, the default is that F1 will provide the
lowest level of Help available on the control that has focus. So if
field level help is provided, you'll get that; if not, it will
default to window level, and if not, it will default to the Help
contents. Shift+F1 provides the What's This? pointer, if you are in a
NT 4.x or Win 95 environment. This is a de facto standard, and it
provides a keyboard analog to a mouse access to Help.
In older versions of Visual Basic, F1 would call WinHelp for the UI
control in focus. Since VB 4.0, this is no longer the case. Now, F1
will display the What's This popup for the control under the cursor,
regardless of which control is in focus. Microsoft says this is the
intended behavior. There is some logic behind this. The drawback of
using F1 to get pop-up help for the component with focus is that you
have to give focus to the required component before pressing F1. This
may be difficult for some users to do without activating the
component, which may be a buttton. Also, the user may have not
noticed the concept of ?focus?. And may be confused as to why the
particular help topic is generated.
Thus, when you have a dialog on your screen, there's no way to
predict what happens when you press F1. The result will vary
depending on the application and how much help is available. In your
own application, the best you can do is make sure pressing F1 has a
reasonably consistent result. Different developers adopt different
solutions, depending on a combination of the desire to follow common
standards and the percieved usability for their specific situation.
For cc:Mail and SmartSuite, Lotus explicitly chose not to implement
What's This? help, in favor of F1, Help button, and other
context-sensitive coverage. Context-sensitive help always goes either
to a procedure or a list of procedures, if more than one fits the
Some of the most experienced WinHelp developers believe that F1
giving field-level help is still too hard a change to grasp for most
</Someone else's explanation>
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com