#14314: Menu event routing problem

wxTrac

unread,

May 16, 2012, 11:09:30 AM5/16/12

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314>

#14314: Menu event routing problem
---------------------+------------------------------------------------------
Reporter: troelsk | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: wxMSW | Version: 2.9-svn
Keywords: mdi | Blockedby:
Patch: 1 | Blocking:
---------------------+------------------------------------------------------
Seen with the docview sample in default mdi mode, patched to make one menu
item disabled.

MDI parent menubar: the menu item is disabled

(...opening a mdi child...)

MDI child menubar: the menu item with the same id is enabled, and appears
as enabled.
But you cannot select it!

If this is made with EVT_UPDATEUI() handlers, same unfortunate result.

I've attached a patch that seems to fix the problem but I doubt that this
is the correct solution.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314>

wxTrac

unread,

May 16, 2012, 6:09:32 PM5/16/12

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:1>

#14314: Menu event routing problem
---------------------+------------------------------------------------------
Reporter: troelsk | Owner:

Type: defect | Status: confirmed

Priority: normal | Milestone:
Component: wxMSW | Version: 2.9-svn
Keywords: mdi | Blockedby:
Patch: 1 | Blocking:
---------------------+------------------------------------------------------

Changes (by vadz):

* status: new => confirmed

Comment:

So what is actually the correct behaviour here? For the item to be
disabled in the child menu bar too or for it to be enabled and work?

FWIW wxGTK currently does the latter and, if I understand the patch
correctly, it does it as well. But is this really the right thing to do?

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:1>

wxTrac

unread,

May 17, 2012, 2:52:00 AM5/17/12

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:2>

#14314: Menu event routing problem
---------------------+------------------------------------------------------
Reporter: troelsk | Owner:

Type: defect | Status: confirmed

Priority: normal | Milestone:
Component: wxMSW | Version: 2.9-svn
Keywords: mdi | Blockedby:
Patch: 1 | Blocking:
---------------------+------------------------------------------------------

Comment(by troelsk):

The menu state dictated by the window in focus should "win" over the menu
state from the main frame class (or app class) I think; currently it is
vice versa.

I've added a patch with EVT_UPDATE_UI() handlers demonstrating this, with
a EVT_UPDATE_UI(Enable) handler in the text view class and a
EVT_UPDATE_UI(Disable) handler in the frame class (actually the app class
because the sample has no derived frame class).

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:2>

wxTrac

unread,

May 17, 2012, 5:31:37 AM5/17/12

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:3>

#14314: Menu event routing problem
---------------------+------------------------------------------------------
Reporter: troelsk | Owner:

Type: defect | Status: confirmed

Priority: normal | Milestone:
Component: wxMSW | Version: 2.9-svn
Keywords: mdi | Blockedby:
Patch: 1 | Blocking:
---------------------+------------------------------------------------------

Comment(by troelsk):

>The menu state dictated by the window in focus should "win" over the menu
state from the main frame

This is how it works with 2.8

Probably related to ticket #14314.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:3>

wxTrac

unread,

May 17, 2012, 5:32:13 AM5/17/12

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:4>

#14314: Menu event routing problem
---------------------+------------------------------------------------------
Reporter: troelsk | Owner:

Type: defect | Status: confirmed

Priority: normal | Milestone:
Component: wxMSW | Version: 2.9-svn
Keywords: mdi | Blockedby:
Patch: 1 | Blocking:
---------------------+------------------------------------------------------

Comment(by troelsk):

Probably related to ticket #13873

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:4>

wxTrac

unread,

Jun 6, 2012, 1:11:08 PM6/6/12

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:5>

#14314: Menu event routing problem
---------------------+------------------------------------------------------
Reporter: troelsk | Owner:

Type: defect | Status: confirmed

Priority: normal | Milestone:
Component: wxMSW | Version: 2.9-svn
Keywords: mdi | Blockedby:
Patch: 1 | Blocking:
---------------------+------------------------------------------------------

Comment(by troelsk):

Maybe just reinstate the 2.8 behaviour which seems to work better. That
is, overriding [the well-known] ProcessEvent() instead of [the mysterious]
overrides of TryBefore() and TryAfter().

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:5>

wxTrac

unread,

Jun 30, 2012, 12:23:01 PM6/30/12

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:6>

#14314: Menu event routing problem
---------------------+------------------------------------------------------
Reporter: troelsk | Owner:

Type: defect | Status: confirmed
Priority: normal | Milestone: 3.0

Component: wxMSW | Version: 2.9-svn
Keywords: mdi | Blockedby:
Patch: 1 | Blocking:
---------------------+------------------------------------------------------

Changes (by vadz):

* milestone: => 3.0

Comment:

Unfortunately 2.8 behaviour has a ton of problems too. In particular, it
called the same handler multiple times for the same event which was really
unexpected. The `TryBefore/After()` functions were my attempt to fix this
but the event handling is so complicated (and particularly so in doc/view
code) that I clearly didn't manage to do it without breaking something
else. But just restoring the old bugs is hardly ideal :-(

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:6>

wxTrac

unread,

May 1, 2013, 1:55:17 PM5/1/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:7>

#14314: Menu event routing problem

-----------------------+----------------------------------------------------
Reporter: troelsk | Owner:

Type: defect | Status: confirmed
Priority: normal | Milestone: 3.0

Component: GUI-all | Version: 2.9-svn
Keywords: mdi event | Blockedby:
Patch: 0 | Blocking:
-----------------------+----------------------------------------------------
Changes (by vadz):

* keywords: mdi => mdi event
* component: wxMSW => GUI-all
* patch: 1 => 0

Comment:

I think the main problem here is that the menu event is sent to the parent
frame instead of the child one in the first place, isn't it? I don't know
how did it work in 2.8 but it would make sense to have the following order
IMHO:

1. wxView
1. wxDocManager
1. wxDocChildFrame
1. wxDocParentFrame
1. wxApp

What do you think?

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:7>

wxTrac

unread,

May 1, 2013, 1:59:38 PM5/1/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:8>

#14314: Menu event routing problem

-----------------------+----------------------------------------------------
Reporter: troelsk | Owner:

Comment(by vadz):

Oops, forgot:
{{{
0. wxDocument
}}}

Whereas currently we get the following:
{{{
0. wxDocument
1. wxView
2. wxDocManager
3. wxDocument
4. wxView
5. wxDocChildFrame
6. wxDocParentFrame
7. wxApp
}}}

I.e. both the document and the view get the event twice which is clearly
bad.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:8>

wxTrac

unread,

May 2, 2013, 1:13:08 PM5/2/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:9>

#14314: Menu event routing problem

-----------------------+----------------------------------------------------
Reporter: troelsk | Owner:

OK, so actually there are 2 problems here:

1. Menu events are sent to the wrong frame in the first place in wxMSW,
this breaks the first example as the menu item is disabled in the parent
frame even if it's enabled in the child. This could be fixed by your patch
but I think it's better to just send the `WM_COMMAND` message to the right
frame from the beginning.
1. wxEvents were handled in the wrong order too which, I think, explained
the second example. I've fixed the order to follow that of comment:7.

I'm going to retest my changes under all platforms and commit them soon,
please test your code and let me know about any remaining problems and,
especially, any regressions. TIA!

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:9>

wxTrac

unread,

May 2, 2013, 8:31:44 PM5/2/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:10>

#14314: Menu event routing problem

-----------------------+----------------------------------------------------
Reporter: troelsk | Owner:

The proposed changes are at http://review.bakefile.org/r/489/ if you'd
like to comment on or simply test them. TIA!

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:10>

wxTrac

unread,

May 3, 2013, 11:16:39 AM5/3/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:11>

#14314: Menu event routing problem

-----------------------+----------------------------------------------------
Reporter: troelsk | Owner:

Comment(by troelsk):

Testing rb489.patch on MSW:

docview sample with the --single option:
File menu items (New/Open/Save/Save as) are nonresponsive
(without the patch the file menu items work except New)

About the order:
1. wxDocument
2. wxView
3. wxDocManager
4. wxDocChildFrame
5. wxDocParentFrame
6. wxApp

It seems strange that wxDocManager should get a crack before (focused)
wxDocChildFrame.
Maybe consider moving wxDocManager down 2 steps,
5. wxDocManager
6. wxApp

PS: I prefer 2 steps, after wxDocParentFrame, because if you want to grab
one of wxDocManager's menu id's (wxID_OPEN, wxID_NEW) it seems natural to
grab them from the main window, together with the bunch of Bind()'s or
EVT_MENU's you normally already have there.
This seems more convenient than deriving from the docmanager class and
grabbing from there.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:11>

wxTrac

unread,

May 3, 2013, 6:56:28 PM5/3/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:12>

#14314: Menu event routing problem

-----------------------+----------------------------------------------------
Reporter: troelsk | Owner:

Comment(by vadz):

I'll check the behaviour in the "--single" case, thanks.

As for the order: what you propose does make sense to me but I think the
current (after patch) order should be the same as in 2.8 (except for
absence of duplication), so I'd rather keep it for compatibility. Or am I
wrong about this?

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:12>

wxTrac

unread,

May 4, 2013, 3:07:34 AM5/4/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:13>

#14314: Menu event routing problem

-----------------------+----------------------------------------------------
Reporter: troelsk | Owner:

Comment(by troelsk):

No, no problem. Compatibility with no duplication is fine.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:13>

wxTrac

unread,

May 4, 2013, 7:59:53 PM5/4/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:14>

#14314: Menu event routing problem

-----------------------+----------------------------------------------------
Reporter: troelsk | Owner:

Comment(by VZ):

(In [73927]) Forward events to active child at MSW, not wx, level in
wxMDIParentFrame.

We want to handle menu (and toolbar) events in the active MDI child before
handling them in the parent frame itself and the existing code achieved
this
by forwarding wxEVT_MENU events at wx event processing level to the active
child. However this was not enough as the underlying MSW WM_COMMAND
message
was still sent to the parent frame only and this could result in wx event
not
being generated at all if the parent frame had a disabled menu item with
the
same ID as (an enabled) item in the child frame, see #14314.

So forward WM_COMMAND directly to ensure that the correct window gets the
event in the first place. And this makes wxEVT_MENU forwarding in
TryBefore()
unnecessary.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:14>

wxTrac

unread,

May 4, 2013, 7:59:59 PM5/4/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:15>

#14314: Menu event routing problem

-----------------------+----------------------------------------------------
Reporter: troelsk | Owner:

(In [73928]) Fix event handling order in doc/view framework.

Ensure that the events are always (provided there is an open document)
processed in the following order:

1. wxDocument
2. wxView
3. wxDocManager
4. wxDocChildFrame
5. wxDocParentFrame
6. wxApp

Do this by forwarding the events from wxDocParentFrame to wxDocChildFrame
first and forward them from there to wxDocManager which -- and this part
remains unchanged -- in turn forwards them to the active wxView which
finally
forwards them to wxDocument. This requires another condition in the event
handling code as we still must forward from wxDocParentFrame to
wxDocManager
itself if there are no active children at all, but this is the only way to
have the same event order in all cases, whether the event is originally
received by wxDocChildFrame or wxDocParentFrame.

Document this and add a unit test verifying that things indeed work like
this.

See #14314.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:15>

wxTrac

unread,

May 4, 2013, 8:01:29 PM5/4/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:16>

#14314: Menu event routing problem

----------------------+-----------------------------------------------------
Reporter: troelsk | Owner:
Type: defect | Status: closed

Priority: normal | Milestone: 3.0
Component: GUI-all | Version: 2.9-svn

Resolution: fixed | Keywords: mdi event
Blockedby: | Patch: 0
Blocking: |
----------------------+-----------------------------------------------------
Changes (by vadz):

* status: confirmed => closed
* resolution: => fixed

Comment:

I've fixed the problem with the "single" mode (and also the still
duplicate handlers in "sdi" mode), thanks again for testing.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:16>

wxTrac

unread,

May 7, 2013, 9:51:06 AM5/7/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:17>

#14314: Menu event routing problem

----------------------+-----------------------------------------------------
Reporter: troelsk | Owner:
Type: defect | Status: reopened

Priority: normal | Milestone: 3.0
Component: GUI-all | Version: 2.9-svn

Resolution: | Keywords: mdi event

Blockedby: | Patch: 0
Blocking: |
----------------------+-----------------------------------------------------

Changes (by troelsk):

* status: closed => reopened
* resolution: fixed =>

Comment:

Sorry, I have another problem with "single" mode. Added patch
demonstrating this:

If, in single mode, you call view->SetFrame(toplevelframe) - which I do
everywhere - event processing gets completely blocked, here, "return
false":

{{{
bool wxDocParentFrameAnyBase::TryProcessEvent(wxEvent& event)
{
if ( !m_docManager )
return false;

// If we have an active view, its associated child frame may have
// already forwarded the event to wxDocManager, check for this:
if ( wxView* const view = m_docManager->GetAnyUsableView() )
{
// Notice that we intentionally don't use wxGetTopLevelParent()
here
// because we want to check both for the case of a child "frame"
(e.g.
// MDI child frame or notebook page) inside this TLW and a
separate
// child TLW frame (as used in the SDI mode) here.
for ( wxWindow* win = view->GetFrame(); win; win =
win->GetParent() )
{
if ( win == m_frame )
return false; // DROPS OUT HERE!!!
}
}

// But forward the event to wxDocManager ourselves if there are no
views at
// all or if we are the frame's view ourselves.
return m_docManager->ProcessEventLocally(event);
}
}}}

In other words, the new event processing expects view->GetFrame() = NULL
always in "single" mode.
Not sure what the fix is.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:17>

wxTrac

unread,

May 7, 2013, 10:39:21 AM5/7/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:18>

#14314: Menu event routing problem

----------------------+-----------------------------------------------------
Reporter: troelsk | Owner:
Type: defect | Status: reopened
Priority: normal | Milestone: 2.9.5

Component: GUI-all | Version: 2.9-svn
Resolution: | Keywords: mdi event
Blockedby: | Patch: 0
Blocking: |
----------------------+-----------------------------------------------------

Changes (by vadz):

* milestone: 3.0 => 2.9.5

Comment:

I just don't understand "single" mode at all, I don't know what is the
relationship between view/frame supposed to be in it :-(

Anyhow, it seems like this could be fixed by checking that only the parent
of the view frame is this one, i.e.
{{{
#!diff
diff --git a/src/common/docview.cpp b/src/common/docview.cpp
index 246d247..4118192 100644
--- a/src/common/docview.cpp
+++ b/src/common/docview.cpp
@@ -2075,15 +2075,24 @@ bool
wxDocParentFrameAnyBase::TryProcessEvent(wxEvent& event)

// already forwarded the event to wxDocManager, check for this:
if ( wxView* const view = m_docManager->GetAnyUsableView() )
{

- // Notice that we intentionally don't use wxGetTopLevelParent()
here
- // because we want to check both for the case of a child "frame"
(e.g.
- // MDI child frame or notebook page) inside this TLW and a
separate
- // child TLW frame (as used in the SDI mode) here.
- for ( wxWindow* win = view->GetFrame(); win; win =
win->GetParent() )
+ wxWindow* win = view->GetFrame();
+ if ( win != m_frame )
{
- if ( win == m_frame )
- return false;
+ // Notice that we intentionally don't use
wxGetTopLevelParent()
+ // here because we want to check both for the case of a child
+ // "frame" (e.g. MDI child frame or notebook page) inside
this TLW
+ // and a separate child TLW frame (as used in the SDI mode)
here.
+ for ( win = win->GetParent(); win; win = win->GetParent() )
+ {
+ if ( win == m_frame )
+ return false;
+ }
}
+ //else: This view is directly associated with the parent frame
(which
+ // can happen in the so called "single" mode in which only
one
+ // document can be opened and so is managed by the parent
frame
+ // itself), there can be no child frame in play so we must
forward
+ // the event to wxDocManager ourselves.

}

// But forward the event to wxDocManager ourselves if there are no
views at
}}}

Does this help/not harm anything else?

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:18>

wxTrac

unread,

May 7, 2013, 10:59:10 AM5/7/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:19>

#14314: Menu event routing problem

----------------------+-----------------------------------------------------
Reporter: troelsk | Owner:

Comment(by troelsk):

I see no harm only improvement, at the moment. I don't know if there is
anything special to understand about the m_viewFrame member, in "single"
mode, it is a simple placeholder as I see it...

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:19>

wxTrac

unread,

May 7, 2013, 11:06:29 AM5/7/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:20>

#14314: Menu event routing problem

----------------------+-----------------------------------------------------
Reporter: troelsk | Owner:

Comment(by vadz):

Well, the question is whether it's supposed to be `NULL` (because there is
no child frame for it) or point to the parent frame (because it's the
closest it has to the "associated frame"). I guess we'll just have to
settle for "either" as the answer to this question though...

I'll commit the change above then, please let me know if it breaks
anything else.

Thanks!

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:20>

wxTrac

unread,

May 7, 2013, 11:07:31 AM5/7/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:21>

#14314: Menu event routing problem

----------------------+-----------------------------------------------------
Reporter: troelsk | Owner:
Type: defect | Status: closed

Priority: normal | Milestone: 2.9.5
Component: GUI-all | Version: 2.9-svn

Resolution: fixed | Keywords: mdi event

Blockedby: | Patch: 0
Blocking: |
----------------------+-----------------------------------------------------

Changes (by VZ):

* status: reopened => closed

* resolution: => fixed

Comment:

(In [73943]) Fix for event propagation in "single document" doc/view mode.

Ensure that the events still get to wxDocManager even when we are using
the
single document mode in which a view can be directly associated with the
parent frame.

Closes #14314.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:21>

wxTrac

unread,

May 7, 2013, 11:27:45 AM5/7/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:22>

#14314: Menu event routing problem

----------------------+-----------------------------------------------------
Reporter: troelsk | Owner:

Comment(by troelsk):

Excellent! Many thanks for your effort in cleaning up docview.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:22>

wxTrac

unread,

May 7, 2013, 11:48:04 AM5/7/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:23>

#14314: Menu event routing problem

----------------------+-----------------------------------------------------
Reporter: troelsk | Owner:

Oops, needs to trap NULL because of the win->GetParent() call below, patch
added

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:23>

wxTrac

unread,

May 7, 2013, 11:56:56 AM5/7/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:24>

#14314: Menu event routing problem

----------------------+-----------------------------------------------------
Reporter: troelsk | Owner:

Comment(by VZ):

(In [73945]) Test for NULL associated frame in doc/view event handling
code.

A view might not have any associated frame at all (this is probably a bad
idea
but we don't seem to explicitly forbid this).

This should have been part of r73943, see #14314.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:24>

wxTrac

unread,

Jun 7, 2013, 4:02:40 AM6/7/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:25>

#14314: Menu event routing problem

----------------------+-----------------------------------------------------
Reporter: troelsk | Owner:
Type: defect | Status: reopened

Priority: normal | Milestone: 2.9.5
Component: GUI-all | Version: 2.9-svn

Resolution: | Keywords: mdi event

Blockedby: | Patch: 0
Blocking: |
----------------------+-----------------------------------------------------

Changes (by troelsk):

* status: closed => reopened
* resolution: fixed =>

Comment:

Toolbar clicks never reach the view, in --mdi mode in wxMSW.
I'm fairly sure that it used to.
See new patch.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:25>

wxTrac

unread,

Jun 11, 2013, 9:05:00 AM6/11/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:26>

#14314: Menu event routing problem
----------------------+-----------------------------------------------------
Reporter: troelsk | Owner:
Type: defect | Status: reopened
Priority: normal | Milestone: 2.9.5
Component: GUI-all | Version: 2.9-svn
Resolution: | Keywords: mdi event
Blockedby: | Patch: 0
Blocking: |
----------------------+-----------------------------------------------------

Comment(by troelsk):

The MDI child frame receives the command, both when you click a menu item
or click the corresponding toolbar button. But in the latter case, instead
of allowing child frame+view+doc a crack at it (msw/window.cpp line 5314),
it delegates the command to the toolbar, msw/window.cpp line 5301,
{{{
return win->MSWCommand(cmd, id);
}}}
The toolbar in turn seems to allow only the main frame window a crack at
it, docmanager+child frame+view+doc gets no (second) crack at it. No
solution from here, it is a bit hard to follow the event flow (esp after
ProcessEvent was split up in 3 methods).

PS: slight comment typo in docview.cpp line 2030,
- // event handlers call order: first the document, then the new and
then the
+ // event handlers call order: first the document, then the view and
then the

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:26>

wxTrac

unread,

Jun 11, 2013, 9:28:23 AM6/11/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:27>

#14314: Menu event routing problem
----------------------+-----------------------------------------------------
Reporter: troelsk | Owner:
Type: defect | Status: reopened
Priority: normal | Milestone: 2.9.5
Component: GUI-all | Version: 2.9-svn
Resolution: | Keywords: mdi event
Blockedby: | Patch: 0
Blocking: |
----------------------+-----------------------------------------------------

Comment(by troelsk):

The toolbar patch I just added makes the toolbar button clicks go the
normal docview route.
This is not a good solution because unfortunately the EVT_UPDATE_UI
handlers are not called.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:27>

wxTrac

unread,

Jun 14, 2013, 9:54:37 AM6/14/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:28>

#14314: Menu event routing problem
----------------------+-----------------------------------------------------
Reporter: troelsk | Owner:
Type: defect | Status: reopened
Priority: normal | Milestone: 2.9.5
Component: GUI-all | Version: 2.9-svn
Resolution: | Keywords: mdi event
Blockedby: | Patch: 0
Blocking: |
----------------------+-----------------------------------------------------

Comment(by troelsk):

Pain. The toolbar is entirely dead in MDI docview apps. Maybe open a new
ticket for this instead of keeping it here? "Toolbar in
wxDocMDIParentFrame is nonresponsive, and toolbar buttons are not updated"

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:28>

wxTrac

unread,

Jun 14, 2013, 10:01:38 AM6/14/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:29>

#14314: Menu event routing problem
----------------------+-----------------------------------------------------

Reporter: troelsk | Owner: vadz
Type: defect | Status: accepted

Changes (by vadz):

* owner: => vadz
* status: reopened => accepted

Comment:

I'll look at this a.s.a.p. but I need to find enough contiguous free time
for this first.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:29>

wxTrac

unread,

Jun 16, 2013, 7:40:48 AM6/16/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:30>

#14314: Menu event routing problem
----------------------+-----------------------------------------------------
Reporter: troelsk | Owner: vadz
Type: defect | Status: accepted
Priority: normal | Milestone: 2.9.5
Component: GUI-all | Version: 2.9-svn
Resolution: | Keywords: mdi event
Blockedby: | Patch: 0
Blocking: |
----------------------+-----------------------------------------------------

Comment(by vadz):

Thanks once again for finding the bug, I do see it perfectly well.

Unfortunately I don't see how to fix it yet :-( The problem is that I now
intercept all `WM_COMMAND`s at parent frame level and send them to the
child frame. But for the toolbar commands the child frame sends them back
to the toolbar itself for processing. And the toolbar has no knowledge of
this frame, being child of the parent frame itself. So the child frame
never gets the event.

With the update UI events it's even worse as their handling never involves
the child frame at all.

So the changes of r73927 will probably need to be reverted and the problem
it fixed (with the disabled menu items) be fixed in some other way.
Although I'm not sure if this fixes the update UI problem, would you have
some simple test for this by chance? And I still don't know how to fix
that other problem with the menus if we do revert it... But it is less
serious than toolbars not working at all, so in the worst case we'd just
live with it -- but at least with working toolbars.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:30>

wxTrac

unread,

Jun 19, 2013, 10:14:36 AM6/19/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:31>

#14314: Menu event routing problem
----------------------+-----------------------------------------------------
Reporter: troelsk | Owner: vadz
Type: defect | Status: accepted
Priority: normal | Milestone: 2.9.5
Component: GUI-all | Version: 2.9-svn
Resolution: | Keywords: mdi event
Blockedby: | Patch: 0
Blocking: |
----------------------+-----------------------------------------------------

Comment(by troelsk):

>would you have some simple test for this by chance?

Added a little more to the sample,
menuevent-problem.3.patch
(includes the original patch, menuevent-problem.patch)

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:31>

wxTrac

unread,

Jun 23, 2013, 9:07:58 AM6/23/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:32>

#14314: Menu event routing problem
----------------------+-----------------------------------------------------
Reporter: troelsk | Owner: vadz
Type: defect | Status: accepted
Priority: normal | Milestone: 2.9.5
Component: GUI-all | Version: 2.9-svn
Resolution: | Keywords: mdi event
Blockedby: | Patch: 0
Blocking: |
----------------------+-----------------------------------------------------

Comment(by VZ):

(In [74274]) Undo "Forward events to active child at MSW, not wx, level in
wxMDIParentFrame."

Unfortunately, forwarding MSW messages only takes care of the menu events
but
not the toolbar ones -- which should be handled in the same way but were
not.

So restore the old behaviour, the problem with menu items disabled in the
parent frame but enabled in the child one will be fixed differently.

This reverts r73927.

See #14314.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:32>

wxTrac

unread,

Jun 23, 2013, 9:08:21 AM6/23/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:33>

#14314: Menu event routing problem
----------------------+-----------------------------------------------------
Reporter: troelsk | Owner: vadz
Type: defect | Status: accepted
Priority: normal | Milestone: 2.9.5
Component: GUI-all | Version: 2.9-svn
Resolution: | Keywords: mdi event
Blockedby: | Patch: 0
Blocking: |
----------------------+-----------------------------------------------------

Comment(by VZ):

(In [74275]) Use child MDI frame menu items in preference to the parent
frame ones.

Look for the item with the given ID in the child frame menu bar first,
before
looking in the parent frame menu bar. This ensures that if an item is
disabled
by the parent frame but then reenabled by the child one, it still
generates
commands as expected instead of being completely ignored.

See #14314.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:33>

wxTrac

unread,

Jun 23, 2013, 9:08:44 AM6/23/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:34>

#14314: Menu event routing problem
----------------------+-----------------------------------------------------
Reporter: troelsk | Owner: vadz
Type: defect | Status: accepted
Priority: normal | Milestone: 2.9.5
Component: GUI-all | Version: 2.9-svn
Resolution: | Keywords: mdi event
Blockedby: | Patch: 0
Blocking: |
----------------------+-----------------------------------------------------

Comment(by VZ):

(In [74276]) Also propagate wxEVT_UPDATE_UI to the child MDI frame.

It seems to make sense to handle wxEVT_UPDATE_UI in the same way as
wxEVT_MENU
as they are often used together. This allows to handle e.g. toolbar
buttons
entirely in the child MDI frame, without any involvement from the parent.

See #14314.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:34>

wxTrac

unread,

Jun 23, 2013, 9:13:49 AM6/23/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:35>

#14314: Menu event routing problem
----------------------+-----------------------------------------------------
Reporter: troelsk | Owner: vadz

Type: defect | Status: closed

Priority: normal | Milestone: 2.9.5
Component: GUI-all | Version: 2.9-svn

Resolution: fixed | Keywords: mdi event

Blockedby: | Patch: 0
Blocking: |
----------------------+-----------------------------------------------------

Changes (by vadz):

* status: accepted => closed

* resolution: => fixed

Comment:

The commits above seem to fix all the problems reported so far for me.

The only remaining problem I'm aware of is that selecting "About" menu
item results in processing the event twice in all of `wxDocument`,
`wxView`, `wxDocManager`, `wxChildFrame` and `wxParentFrame` because it's
first handled at the child level but then propagated upwards to the parent
where it's handled again. Unfortunately I don't see any way to avoid this
and from some point of view it actually makes sense as both the child and
the parent have a menu item with this ID.

A more annoying problem is that completely different code paths are used
for menu and toolbar event handling. This results in e.g. r73927 working
for the menus but not the toolbars. It would be nice to somehow reconcile
them but this is clearly not going to be simple...

Also, I suspect forwarding of `wxEVT_UPDATE_UI` events in r74276 might
create problems too. But until it does, let's do it like this, it does
seem convenient.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:35>

wxTrac

unread,

Jun 25, 2013, 9:46:22 AM6/25/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:36>

#14314: Menu event routing problem
----------------------+-----------------------------------------------------
Reporter: troelsk | Owner: vadz
Type: defect | Status: closed
Priority: normal | Milestone: 2.9.5
Component: GUI-all | Version: 2.9-svn
Resolution: fixed | Keywords: mdi event
Blockedby: | Patch: 0
Blocking: |
----------------------+-----------------------------------------------------

Comment(by troelsk):

No problems seen here so far. Thanks!

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:36>

wxTrac

unread,

Jul 3, 2013, 6:18:45 PM7/3/13

to wx-...@googlegroups.com

Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:37>

#14314: Menu event routing problem
----------------------+-----------------------------------------------------
Reporter: troelsk | Owner: vadz
Type: defect | Status: closed
Priority: normal | Milestone: 2.9.5
Component: GUI-all | Version: 2.9-svn
Resolution: fixed | Keywords: mdi event
Blockedby: | Patch: 0
Blocking: |
----------------------+-----------------------------------------------------

Comment(by VZ):

(In [74357]) Prevent duplicate menu event processing in MDI windows.

Record the object propagating the given event upwards in the event object
itself and use it in wxMDIParentFrame to determine whether the event being
handled is already coming from wxMDIChildFrame and avoid sending it back
for
processing it there again in this case.

This is ugly and makes wx event processing even more complex but this is
the
only way I could find to ensure that

(a) Both the child and the parent frames get the events from the toolbar
(even though the toolbar parent is the parent frame and hence normally
the child wouldn't get notified about them at all and so the
forwarding
at wxMDIParentFrame level is required to make this work).

(b) The child gets the event only once, whether it comes from a toolbar
(and
hence indirectly via the parent frame) or from the child menu (and
hence
directly to the child, at least in wxMSW).

This commit fixes the event propagation unit test case, at least under MSW
and
GTK.

See #14314.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/14314#comment:37>

Reply all

Reply to author

Forward