A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I am trying to figure out how to make a VC++ application context-help sensitive.
The application is the kind of GUI that really could use a "help question mark button" approach. IE: click the question mark button in the caption bar, cursor turns into a question mark, and the next control that is clicked results in help being invoked for that control.
We have the following constraints on our UI:
1) There is no caption bar; all we show is the window client area (so the style WS_EX_CONTEXTHELP is apparently out for at least creating the help button.)
2) The UI controls are user drawn and don't support a concept of visible focus, so using F1 on the currently focused button is a non-starter. Users would not be able to see the focused control (which is why I am describing a WS_EX_CONTEXTHELP based approach).
I used Spy on a small test app with WS_EX_CONTEXTHELP enabled, and observed the WM_NCLBUTTONDOWN message and the return value HTHELP which apparently triggers the "help mode".
Ideally, there would be an API function that we could call that would have the same effect as pressing the question mark button enabled by WS_EX_CONTEXTHELP. IE, a function call would 1) turn the cursor into a question mark and 2) generate a WM_HELP message when a control was clicked in that mode, also restoring the cursor. Obviously we cant' initiate WM_NCLBUTTONDOWN messages on our own (can we?)
Thanks for any "winhelp" (ha ha).
Not much help, but we considered doing the same a few years back and finally decided a universal F1 to bring up the help system was enough and the user could find what they needed in the TOC or index. Never got any complaints... I seem to recall concluding though we really needed to have designed context-based help in from the start if we wanted it to work. (It was a legacy MFC app).
Monday, April 10, 2006
The reason that context help is needed for this application is that there are relatively few (<5), but very complex, forms in the project. One "setup" form contains more than 10 tabs, each with a couple of dozen controls. And our user base is computer-illiterate and would probably not be willing to refer manually to a large help page.
Hmmm, sounds like you truly need it then. I think we had left off with the idea of just having the user position the cursor on the desired field and press F1, then we'd read the current cursor position and since we knew which form or dialog was currently up, we'd iterate through the controls' rectangles and figure out which one it's in. Then we'd lookup the right spot in the help index via a gigantic hardcoded table... that was the next candidate after "screw it, just show them the TOC to the help."
Monday, April 10, 2006
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz