Re: [lmi] Accessing html help while an XRC dialog is active

[Greg Chicares]

On 2008-03-18 18:38Z, Vaclav Slavik wrote:
> Greg Chicares wrote:
>> Would this work for wxGTK? (We need to make sure lmi works at
>> least as well on a free OS as on msw--it's FSF policy.) The wx
>> documentation says "on GTK, only menu commands are supported"
>> by wxAcceleratorTable, but I'm not sure exactly what that means
>> here.
> 
> It means that the accelerator emits the same event that is send
> when a menu item is selected and not the event sent when a button
> is clicked. This turned out to be very easy to fix in wxGTK.

It'd be great if you could also update the documentation, whose
comments on wxGTK kind of scared me initially. BTW, here:

http://docs.wxwidgets.org/trunk/classwx_accelerator_table.html
  wxAcceleratorTable (const wxAcceleratorTable &bitmap)

the parameter name 'bitmap' is probably a cut-and-paste accident.

> Moreover, I realized that you don't, in fact, need to handle
> EVT_BUTTON(wxID_HELP) in MvcController, because wxID_HELP handler
> is in Skeleton, so it just has to handle wxID_HELP button events too:

Modification to 'main_wx.cpp' committed 20080320T0247Z. That's
the patch hunk that makes the "Help" pushbutton work.

As for 'mvc_controller.cpp', the other file in the patch--in the
following hunk, I guess you might be using some later version
than wx-2.8.7, or maybe it's just that I haven't yet applied one
of your wx patches--but this didn't compile because it found no
Add() member:

> --- mvc_controller.cpp  28 Feb 2008 03:39:26 -0000      1.19
> +++ mvc_controller.cpp  18 Mar 2008 16:11:14 -0000
> @@ -129,6 +129,11 @@
>          ,wxEVT_INIT_DIALOG
>          ,&MvcController::UponInitDialog
>          );
> +
> +    // bind F1 to the Help button:
> +    wxAcceleratorTable accel;
> +    accel.Add(wxAcceleratorEntry(wxACCEL_NORMAL, WXK_F1, wxID_HELP));
> +    SetAcceleratorTable(accel);

No problem--it took me only a moment to reformulate it:

+    wxAcceleratorEntry const a(wxACCEL_NORMAL, WXK_F1, wxID_HELP);
+    SetAcceleratorTable(wxAcceleratorTable(1, &a));

but I haven't applied that change, at least not yet.

With HEAD as of right now (without that change):
 - the "Help" pushbutton always opens html help
 - Shift-F1 (or the [?]-box alternative) pops up contextual help
 - if a modal dialog is active, F1 is equivalent to Shift-F1
 - if no modal dialog is active, F1 opens html help
That's good enough IMO, but I invite other opinions.

With that 'mvc_controller.cpp' change, however:
 - the "Help" pushbutton still opens html help
 - Shift-F1 (and [?]) still pop up contextual help
 - F1 always opens html help; but see (A) below
 - but if a modal dialog is active...see (B) below

(A) With msw-xp at least, pressing F1 when the "File | Open"
dialog is displayed always pops up contextual help, instead of
opening html help.

(B) Try this in lmi with the 'mvc_controller.cpp' change:

  alt-F N I
  hover mouse over "Cancel" pushbutton, but don't click anything
  press F1

Here's what happens:

  - html help appears, but loses focus right away
  - the lmi dialog "seems to" regain focus (but see below)
  - contextual help for the "Policy" listbox appears at the
    mouse position--that is, this defect reemerges:
      http://lists.nongnu.org/archive/html/lmi/2008-02/msg00062.html

I speculate that what's really happening is that html help loses
focus to the contextual-help popup--and when that popup appears,
it causes the lmi dialog (which I guess is its parent) to rise in
the z-order so that it occults the html help window. I further
speculate that this occultation might be prevented by suppressing
the wx help provider that serves up contextual help.

Again, I think HEAD right now is just fine. It gives a context-
dependent meaning to F1, which could be seen as less than ideal;
but that context dependence can't be removed completely because
of (A) above. And if we change 'mvc_controller.cpp' as above,
then contextual help would require Shift-F1; but I suspect that
some users would consider Shift-F1 "difficult" or "unusual".
Sure, Shift-F1 has had that meaning for decades, but contemporary
msw users don't know the CUA meaning of Ctrl-Ins either.