Opened 8 years ago

Closed 5 years ago

Last modified 5 years ago

#11923 closed defect (fixed)

[wxOSX-Cocoa] Crash in Layout Sample

Reported by: jatupper Owned by: csomor
Priority: normal Milestone: 3.0.0
Component: wxOSX Version:
Keywords: Cc:
Blocked By: Blocking:
Patch: no


Revision 63919
OS X 10.5.8


  • launch layout sample
  • select File / Test wxFlexSizer...
  • press command-Q


  • the wxWidgets Layout Demo frame goes away
  • the Flex Sizer Test Frame remains


  • click on "Help" in the menu bar


  • "Bus error"

(The "Bus error" being the topic of this ticket.)

Change History (6)

comment:1 Changed 8 years ago by vadz

  • Milestone set to 3.0
  • Status changed from new to confirmed

I can still see this with the current svn. The problem seems to be that

  1. Cmd-Q closes just the main frame and not all of them.
  2. The main frame remains "associated" with the menu even though it doesn't exist any more.

I'm not sure if (2) needs to be fixed or whether it shouldn't arise in the first place but (1) definitely should be.

Stefan, will you be able to look at this and/or at least tell me where does this need to be fixed? The frame/menu logic in wxOSX is rather unclear to me.

comment:2 Changed 8 years ago by csomor

  • Owner set to csomor
  • Status changed from confirmed to accepted

I'll look at this

comment:3 Changed 6 years ago by vadz

I think the root problem is that we handle Cmd-Q as "closing the window" but it doesn't work like this under Mac, it should really close all windows.

Unfortunately this is not compatible with the idea of sending this event to MyFrame::OnQuit() as we do now. The only solution I see is to still do this, but handle quit command specially and close all the other top level windows too if any still exist after it's handled normally.

This does raise new questions too, e.g. what should we do if some window refuses to close because it has unsaved changes?

Perhaps instead we should just document that the main frame "Quit" command handler is required to close all windows? And implement this as default behaviour inside wx itself?

This is a rather fundamental question so it would be great to decide something about this before 3.0.

comment:4 Changed 5 years ago by csomor

the crash is duplicate for #12402, there's no wxMenuBar instance anymore, so the crash is fixed, but the inconsistency is still there and we should think about the best behavior

comment:5 Changed 5 years ago by vadz

  • Resolution set to fixed
  • Status changed from accepted to closed

Sorry, I don't know any more what did I have in mind when writing comment:3 :-( There doesn't seem to be any inconsistency here, the sample behaves in the same way under MSW. As the child frame is created without parent (i.e. with NULL parent), it remains opened even when the main frame is closed. The sample is actually badly written (and I'll fix this) but other than that I don't really see any problem here. So if the crash is fixed, I'm closing this one.

comment:6 Changed 5 years ago by VZ

(In [74070]) Don't create multiple parent-less top level frames in layout sample.

This resulted in unexpected behaviour if the main frame was closed while the
other ones were still shown as they remained shown and had to be hunted and
closed one by one to make the application exit.

Fix this simply by creating all the other frames as children of the main one.
This also results in better UI when minimizing and restoring the main frame.

Also get rid of unused position parameters in child frame constructors and get
rid of the title parameter which is not really needed as it's always the same

See #11923.

Note: See TracTickets for help on using tickets.