[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Two trifling help-cursor anomalies

From: Vadim Zeitlin
Subject: Re: [lmi] Two trifling help-cursor anomalies
Date: Fri, 29 Feb 2008 15:23:21 +0100

On Thu, 28 Feb 2008 19:56:14 +0000 Greg Chicares <address@hidden> wrote:

GC> (1) In lmi:
GC>   alt-F N I
GC>   click the [?] box (cursor correctly changes)
GC>   click any notebook tab other than the current one
GC> The notebook page changes. Other msw apps, including the ms
GC> spreadsheet and word processor, don't change the page; instead,
GC> the cursor simply reverts to its normal form, as though the
GC> user had (e.g.) clicked on the dialog's title bar.

 I've looked into it and we simply don't get the help notifications
(WM_HELP messages) when the "?" cursor is clicked on a tab. Instead we
receive the simple left button click message from Windows so the code,
logically enough, handles it as a normal click. I don't really know what is
going on here and why isn't the help message being sent by Windows -- but
it is not.

 So right now the only solution I see is to synthesize the WM_HELP
ourselves by checking if we're in the context-sensitive help mode when the
notebook is clicked. The trouble is that I don't really know how to detect
if we're in this mode, searching MSDN yields EVENT_SYSTEM_CONTEXTHELPSTART
notification but its description is not exactly encouraging:

        A window has entered context-sensitive Help mode. 

        This event is not sent consistently by the system. This is a known
        issue and is being addressed. 

I love Microsoft documentation being honest but I don't see any other way
so maybe it's still worth trying to use this notification and see by
ourselves just how bad the problem really is (e.g. if it manifests itself
only on the systems running Hebrew Windows 98 it's probably good enough for
LMI needs...).

 BTW, a small digression to explain why this works in Word and Excel: you
should know that these programs are really bad examples for checking the
behaviour of the standard controls for a simple reason that they do not use
them at all. This is rather incredible when you think about it (basically
Microsoft Office almost entirely reimplements user32.dll!) but it can be
easily checked with Spy++ or any other similar tool: when you look at the
"Options..." dialog of either of these applications, which contains dozens
if not hundreds of the controls, Spy shows that there is only one native
HWND corresponding to all of them. So Office draws all these "controls"
itself on the dialog manually (this is also clear from the design of Excel4
dialog box API if you happen to be unfortunate enough to have dealt with
it...) and handles their input manually too as the system can only do this
for real windows. This is why it can show help for tabs correctly so easily
-- they're not really different from any other controls for them, they have
to do everything themselves anyhow.

GC> (2) In ms "word 97" and "excel 97", Shift-F1 gives contextual
GC> help even on static controls.

 Hmm, so it does in my quick test. "?"-clicking it always works while
Shift+F1 works if the focus is not on another control. This is, admittedly,
a bit hard to achieve in a dialog box with the other focusable controls as
the focus would go to them usually. So maybe I should start by asking how
exactly would you like this to work?

 IMHO "?"-clicking on the static controls would be used much more often.
And here one possible improvement could be to show the help text of the
next control following the static one as normally the label and the control
it's used with should share the same help text. OTOH there can also be
(rare but not impossible) situations when they do not.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]