lmi
[Top][All Lists]
Advanced

[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&)




reply via email to

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