Re: [lmi] MDI child frame and wxEVT_MENU_HIGHLIGHT

[Greg Chicares]

On 2016-03-30 13:36, Vadim Zeitlin wrote:
> On Wed, 30 Mar 2016 13:09:33 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> 
> https://github.com/vadz/lmi/pull/8/commits/60ddc3976b8b0c1a3a966e032d10e144d46c9ebb
> GC> | Remove the attempts to use MDI parent status bar for menu help display.
> GC> |
> GC> | This code actually had no effect because the MDI child frame never 
> received
> GC> | wxEVT_MENU_HIGHLIGHT anyhow and the help was (correctly) displayed in 
> the
> GC> | parent frame status bar just because this is where all the events went.
> GC> 
> GC> Just to be sure, let me ask whether you carefully read lines 29-58 here:
> GC>   
> http://svn.savannah.nongnu.org/viewvc/lmi/trunk/docmdichildframe_ex.hpp?annotate=6443&root=lmi
> GC> I'm quite sure that this code did have an effect eleven years ago when it 
> was
> GC> written, and that comment block explains why. If you're saying that was 
> never
> GC> true even in 2005, then I'd be surprised.
> 
>  To be honest, I don't remember whether I had noticed this comment and I
> guess it's possible that things worked differently in 2005 (if you remember
> which wxWidgets version lmi used back then, I could test it, but svn
> history only starts from the end of 2007, so I don't even know what to
> test).

The version of wx was certainly no later than 2.5.4, and probably rather older.
I don't think it's worth rewinding the clock that far to check an ancient issue
that I may perhaps have misunderstood at that time.

> But I am quite sure that this code is not needed now and that things
> work correctly without it which, I think, is what really counts.

Okay. I tested lmi with this change, and menu-item strings always do seem to
display correctly on the MDI parent's statusbar. The automated GUI tests find
no problem. Before applying the patch, I added code to pop up a messagebox
whenever the child frame's menu-highlight handler was called, and I couldn't
find a way to cause that messagebox to appear. Therefore, I'll apply this
patch soon.

This leaves 'docmdichildframe_ex.?pp' virtually empty. Please take a look at
it along with me. I think it does nothing at all except supply some default
arguments:

    DocMDIChildFrameEx
        (wxDocument*       doc
        ,wxView*           view
        ,wxMDIParentFrame* parent
        ,wxWindowID        id     = wxID_ANY
        ,wxString   const& title  = "Loading..."
        ,wxPoint    const& pos    = wxDefaultPosition
        ,wxSize     const& size   = wxDefaultSize
        ,long int          style  = wxDEFAULT_FRAME_STYLE
        ,wxString   const& name   = "child frame"
        );

The first three are required by base class wxDocMDIChildFrame anyway. The
window ID has no default in the base class, but I suppose wxID_ANY doesn't
do anything useful here. The pos, size, and style defaults here match the
base class's defaults.

That leaves the string arguments. 'name' defaults to
  common/framecmn.cpp:extern WXDLLEXPORT_DATA(const char) wxFrameNameStr[] = 
"frame";
which is as good as "child frame" above. As for 'title', I think lmi always
sets it anyway after the window is created. If the base class's default is
an empty string, then displaying "Loading..." may have slight debugging
value in the case that instantiation fails on some intermediate step, but
that trivial benefit can't justify subclassing this whole thing in lmi.

Thus, unless I'm missing something, 'docmdichildframe_ex.?pp' should be
eradicated.