[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] UpdateUI problems in main_wx.cpp
From: |
Greg Chicares |
Subject: |
Re: [lmi] UpdateUI problems in main_wx.cpp |
Date: |
Thu, 18 Sep 2008 15:26:27 +0000 |
User-agent: |
Thunderbird 2.0.0.16 (Windows/20080708) |
Let me re-ask the questions here:
http://lists.nongnu.org/archive/html/lmi/2008-08/msg00035.html
in the form of the following patch. I had vainly hoped that recent
changes to HEAD might have removed some mistakes that were preventing
this stuff from working, but...no such luck. As explained in the
message cited above, I suspect that I still don't understand Skip()
well enough.
Index: main_wx.cpp
===================================================================
RCS file: /sources/lmi/lmi/main_wx.cpp,v
retrieving revision 1.117
diff -U 3 -r1.117 main_wx.cpp
--- main_wx.cpp 17 Sep 2008 17:29:36 -0000 1.117
+++ main_wx.cpp 18 Sep 2008 15:17:47 -0000
@@ -150,8 +150,6 @@
EVT_MENU(XRCID("window_tile_vertically"
),Skeleton::UponWindowTileVertically )
EVT_MENU_OPEN( Skeleton::UponMenuOpen
)
EVT_TIMER(wxID_ANY ,Skeleton::UponTimer
)
-// TODO ?? There has to be a better way.
-/*
EVT_UPDATE_UI(XRCID("edit_cell"
),Skeleton::UponUpdateInapplicable)
EVT_UPDATE_UI(XRCID("edit_class"
),Skeleton::UponUpdateInapplicable)
EVT_UPDATE_UI(XRCID("edit_case"
),Skeleton::UponUpdateInapplicable)
@@ -167,7 +165,6 @@
EVT_UPDATE_UI(XRCID("delete_cells"
),Skeleton::UponUpdateInapplicable)
EVT_UPDATE_UI(XRCID("column_width_varying"
),Skeleton::UponUpdateInapplicable)
EVT_UPDATE_UI(XRCID("column_width_fixed"
),Skeleton::UponUpdateInapplicable)
-*/
END_EVENT_TABLE()
#ifndef LMI_MSW
@@ -722,7 +719,7 @@
window_previous->Enable(1 < child_frame_count);
}
}
- // (else) Parent menu enablement could be handled here, but, for
+ // (else) Frame menu enablement could be handled here, but, for
// now at least, none is required.
}
@@ -1025,22 +1022,45 @@
wxSafeShowMessage("Terminating due to unhandled exception.", "Fatal
error");
}
-// TODO ?? An unsuccessful experiment.
void Skeleton::UponUpdateInapplicable(wxUpdateUIEvent& event)
{
-// This handler seems to override mdi childrens'.
-// e.Enable(0 != frame_->GetChildren().GetCount());
+ event.Skip();
+
+ // Here, my (apparently false) hope is that this handler is always
+ // called, and always disables the "inapplicable" toolbar buttons;
+ // and that Skip() lets the *active* MDI child window override that
+ // and enable whatever buttons are "applicable" for it. However, if
+ // I open a '.cns' file and a '.db4' file, then close the '.cns'
+ // file, all toolbar buttons remain enabled, even though they're
+ // "inapplicable" to '.db4' files, which have no handler that would
+ // enable them. What am I misunderstanding?
+ event.Enable(false);
+
+ // Would it be better to Connect() this after the frame is created?
+ // Is it even conceivable that this would matter, or is it definitely
+ // impossible to call a EVT_UPDATE_UI handler before a frame exists?
+ if(!frame_) return;
-/*
-This doesn't undo that override.
- e.Enable(false);
- if(0 != frame_->GetChildren().GetCount())
+ // I think that not all child windows are necessarily MDI children.
+ //
+ // Apparently we don't need to continue counting once we've found
+ // any MDI child window. But optimizations like that can be deferred
+ // until we get the behavior right.
+ //
+ int child_frame_count = 0;
+ wxWindowList wl = frame_->GetChildren();
+ for(wxWindowList::const_iterator i = wl.begin(); i != wl.end(); ++i)
{
- e.Skip();
+ child_frame_count += !!dynamic_cast<wxMDIChildFrame*>(*i);
+ }
+ if(0 == child_frame_count)
+ {
+ event.Enable(false);
+ // It seems necessary to call Skip(false) here. But why? There
+ // is no MDI child, so who else could have a handler that would
+ // reenable the button?
+ event.Skip(false);
}
-*/
-
-// Presumably we need to use ProcessEvent(), somehow.
}
void Skeleton::UponWindowCascade(wxCommandEvent&)