BUG in wxWindowBase::OnSysColourChanged(), trunk

[andim2]

Hi,

[caught by an ASSERT in my app, using 2.8.10]

2464 // propagate the colour change event to the subwindows
2465 void wxWindowBase::OnSysColourChanged(wxSysColourChangedEvent& event)
2466 {
2467 wxWindowList::compatibility_iterator node = GetChildren().GetFirst();
2468 while ( node )
2469 {
2470 // Only propagate to non-top-level windows
2471 wxWindow *win = node->GetData();
2472 if ( !win->IsTopLevel() )
2473 {
2474 wxSysColourChangedEvent event2;
2475 event.SetEventObject(win);
2476 win->GetEventHandler()->ProcessEvent(event2);
2477 }
2478····
2479 node = node->GetNext();
2480 }
2481····
2482 Refresh();
2483 }
2484····

Million dollar question: what's wrong?

Yup, event <--> event2.

Maybe this even warrants cooking up a semantic patch to check against other
such inconvenient mismatches in this highly prominent triple-sequence of event
handling in all other places...

Andreas Mohr

[andim2]

Side note: with a const-reference signature of this handler, the bug would have been stopped cold in its tracks...

[vadz]

Replying to andim2:

Side note: with a const-reference signature of this handler, the bug would have been stopped cold in its tracks...

It would also make it impossible to call event.Skip() or event.Veto()...

OTOH not making SetEventObject() public (but requiring to pass it in the ctor because all events must have it) would have made it impossible. Unfortunately it's impossible to do this now.

[VZ]

(In [62818]) Fix event object in wxSysColourChangedEvent.

The handler for this event in the base class incorrectly changed the event
object of the original event instead of setting it for the event being sent to
the window children as it was supposed to.

Closes #11458.