Opened 12 years ago

Closed 2 years ago

Last modified 2 years ago

#4355 closed defect (fixed)

Dialogs end up behind wxFRAME_FLOAT_ON_PARENT frames

Reported by: chodges_1 Owned by: csomor
Priority: normal Milestone:
Component: wxOSX Version:
Keywords: Cc: chodges_1, csomor, robind
Blocked By: Blocking:
Patch: yes

Description (last modified by vadz)

When you create a frame in wxMac using the wxFRAME_FLOAT_ON_PARENT style any modal dialogs you pop up with the frame as the parent actually show up BEHIND the frame? On windows this work situation works properly.

Attachments (1)

minsample_framedlg_stack.diff download (5.1 KB) - added by johnr 4 years ago.

Download all attachments as: .zip

Change History (21)

comment:1 Changed 12 years ago by csomor

I've committed a fix to WX_2_8_BRANCH, could you please retest



comment:2 Changed 12 years ago by chodges_1

I have a dumb question. Is there anyway to browse the WX_2_8_BRANCH code using my browser? rather than downloading the entire project using CVS?

comment:3 Changed 12 years ago by chodges_1

I have a dumb question. Is there anyway to browse the WX_2_8_BRANCH code using my browser? rather than downloading the entire project using CVS?

comment:5 Changed 12 years ago by chodges_1

Hi Stefan:

Okay I finally got a chance to try this out. The good news: The windows now show up in front of their parent like they should.

The bad news: I'm now getting all sorts of errors in SetWindowGroupParent:

#0 0x92deeea0 in SetWindowGroupParent
#1 0x0032feed in wxDialog::DoShowModal
#2 0x0032ff7b in wxDialog::Show
#3 0x0033013e in wxDialog::ShowModal
#4 0x0013921a in monoLogsFrm::OnMapIt
#5 0x00306122 in wxEvtHandler::ProcessEventIfMatches
#6 0x003062b9 in wxEventHashTable::HandleEvent
#7 0x0030673d in wxEvtHandler::ProcessEvent
#8 0x003c0251 in wxMenuBase::SendEvent
#9 0x0036a013 in wxMacWindowEventHandler

comment:6 Changed 12 years ago by csomor

so you've copied the code from MacCreateRealWindow ? what are the errors you get in SetWindowGroupParent ? is this a special dialog window ?



comment:7 Changed 12 years ago by chodges_1

Hi Stefan:

What I did was checkout the entire WX_2_8_BRANCH and then I updated the following folders in my build environment:


Then I rebuilt my static libraries. I'm not at my dev. machine right now but I would assume that the MacCreateRealWindow code is somewhere in the src/mac folder?

I'll have to check what the exact errors that I got when I get back to my dev box.


comment:8 Changed 12 years ago by chodges_1

What I figured out is that the problem is resolved if I comment out a few lines in the wxDialog source code. In the method DoShowModal this is what I've taken out:

void wxDialog::DoShowModal()

wxCHECK_RET( IsModalShowing(), wxT("DoShowModal() called twice") );


SetFocus() ;

WindowRef windowRef = (WindowRef) MacGetWindowRef();
WindowGroupRef windowGroup;
WindowGroupRef formerParentGroup;
if ( GetParent() == NULL )

windowGroup = GetWindowGroup(windowRef) ;
formerParentGroup = GetWindowGroupParent( windowGroup );
SetWindowGroupParent( windowGroup, GetWindowGroupOfClass( kMovableModalWindowClass ) );

BeginAppModalStateForWindow(windowRef) ;

while ( IsModalShowing() )

wxTheApp->MacDoOneEvent() ;
calls process idle itself


EndAppModalStateForWindow(windowRef) ;


if ( GetParent() == NULL )

SetWindowGroupParent( windowGroup , formerParentGroup );



The code was failing on the SetWindowGroupParent. And no I'm not using any special dialog window. I just have a normal class that extends wxDialog. The parent in this case is a wxFrame. And it fails consistently. And I'm using the latest code from the WX_2_8_BRANCH.


comment:9 Changed 12 years ago by csomor

if a wxFrame is the parent, then this behaviour seems strange, when debugging does it enter the first GetParent() == NULL ? if not, does it enter the second - any indications why ?



comment:10 Changed 11 years ago by wxsite

  • Status changed from assigned to confirmed

transitioning old 'assigned' status to new 'confirmed' status

comment:11 follow-up: Changed 5 years ago by oneeyeman

With this patch:

diff -bru wxWidgets.orig/samples/dialogs/dialogs.cpp wxWidgets/samples/dialogs/dialogs.cpp
--- wxWidgets.orig/samples/dialogs/dialogs.cpp	2014-07-31 21:15:11.000000000 -0700
+++ wxWidgets/samples/dialogs/dialogs.cpp	2014-09-06 21:00:08.000000000 -0700
@@ -1704,7 +1704,7 @@
     wxFrame *frame = new wxMiniFrame(this, wxID_ANY, wxT("Mini frame"),
                                      wxDefaultPosition, wxSize(300, 100),
-                                     wxCAPTION | wxCLOSE_BOX);
+                                     wxCAPTION | wxCLOSE_BOX | wxFRAME_FLOAT_ON_PARENT );
     new wxStaticText(frame,
                      wxT("Mini frames have slightly different appearance"),

the mini frame appears on top of the main frame and there is no error.
Tested on Cocoa build.

This can be closed.

comment:12 Changed 5 years ago by vadz

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

comment:13 in reply to: ↑ 11 Changed 5 years ago by johnr

Replying to oneeyeman:

With this patch:
the mini frame appears on top of the main frame and there is no error.
Tested on Cocoa build.

This can be closed.

Given the ticket was about a modal dialog appearing behind its parent frame it seems invalid to test with a non modal mini frame on a parent frame.

comment:14 Changed 5 years ago by neis

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:15 Changed 5 years ago by johnr

This remains a problem and can be reproduced with the following patch. Subsequent dialogs parented to the obscured dialog are shown correctly.

Index: samples/minimal/minimal.cpp
--- samples/minimal/minimal.cpp	(revision 78396)
+++ samples/minimal/minimal.cpp	(working copy)
@@ -73,6 +73,41 @@
+class MyDialog : public wxDialog
+    MyDialog( wxWindow* parent );
+    void OnButton( wxCommandEvent& event );
+    bool boolChoice;
+MyDialog::MyDialog( wxWindow* parent )
+    Create( parent, wxID_ANY, "MyDialog" );
+    wxButton* butt = new wxButton( this, wxID_ANY, "click me again" );
+    butt->Bind( wxEVT_BUTTON, &MyDialog::OnButton, this );
+void MyDialog::OnButton( wxCommandEvent& event )
+    if( boolChoice )
+    {
+        wxTextEntryDialog dlg( this, "message", "GetTextFromUserPromptStr" );
+        dlg.ShowModal();
+    }
+    else
+    {
+        wxMessageDialog dlgMess( this, "message dialog" );
+        dlgMess.ShowModal();
+    }
+    boolChoice = !boolChoice;
 // ----------------------------------------------------------------------------
 // constants
 // ----------------------------------------------------------------------------
@@ -131,6 +166,8 @@
     // created initially)
+    MyDialog* dlg = new MyDialog( frame );
+    dlg->Show();
     // success: wxApp::OnRun() will be called which will enter the main message
     // loop and the application will run. If we returned false here, the
     // application would exit immediately.
@@ -143,7 +180,8 @@
 // frame constructor
 MyFrame::MyFrame(const wxString& title)
-       : wxFrame(NULL, wxID_ANY, title)
+       : wxFrame(NULL, wxID_ANY, title, wxDefaultPosition, wxDefaultSize,
     // set the frame icon

comment:16 Changed 4 years ago by johnr

Added minsample_framedlg_stack.diff as a diff to the minimal sample for testing stacks of frames and dialogs. Patch adds buttons to the frame allowing creation of multiple child frames with default or float on parent style. Each frame can subsequently add further multiple frames or modal or non modal child dialogs. Child dialogs can also show a child messagedialog or wxTextEntryDialog. The patch is useful for checking ZOrder problems.

I have tried several stategies involving window levels. None were completely successful with this ticket's problem.

  1. Added kCGFloatingWindowLevel to child dialogs of frames with wxFRAME_FLOAT_ON_PARENT style. This works initially but the dialog can later retreat behind its parent if the app is deactivated and subsequently reactivated eg from the dock.
  1. Added kCGUtilityWindowLevel to child dialogs of frames with wxFRAME_FLOAT_ON_PARENT style. This had problems showing modal dialogs over the frame's child dialog. The subsequent dialog did flash on screen briefly but disappeared.
  1. Used [parentNSWindow addChildWindow:m_macWindow ordered:NSWindowAbove] (currently used for modal dialogs) for wxFRAME_FLOAT_ON_PARENT style frames and nonmodal dialogs rather than specifying a window level. This worked infallibly for zorder but the frames and dialogs moved when their parent moved which is non-standard behaviour for wxWidgets.

The area left to look at is the assigning and reassigning of focus / firstresponder for windows which seems amiss for strategy 1 above.

Changed 4 years ago by johnr

comment:17 Changed 2 years ago by lanurmi

  • Component changed from old wxOSX/Carbon port to wxOSX
  • Patch set
  • Summary changed from wxFRAME_FLOAT_ON_PARENT problem to Dialogs end up behind wxFRAME_FLOAT_ON_PARENT frames

I have a possible fix for this and some other wxFRAME_FLOAT_ON_PARENT-related problems at GitHub (4 commits).

Disclaimer: I don't really know much about Cocoa, and while my branch appears to solve all the problems I wanted to solve, I hope it doesn't break something else in the process.

Development and testing was done on OS X Yosemite 10.10.5.

comment:18 Changed 2 years ago by vadz

  • Description modified (diff)

I can't really comment on the validity of these changes, but if they fix the problem, let's apply them and see if it breaks something else.

Could you please make a PR with these changes for ease of reviewing and merging? TIA!

comment:19 Changed 2 years ago by Lauri Nurmi <lanurmi@…>

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

In e36aa6475219d3e2fbbbdd97eb46429bd8851880/git-wxWidgets:

Set proper level also for non-modal dialogs in wxOSX

Fixes #4355

comment:20 Changed 2 years ago by Vadim Zeitlin <vadim@…>

In ef3c0c83af5f9854f7ce689642b856219bfb5d28/git-wxWidgets:

Merge branch 'osx-fix-dialog-level-on-floating-frames-master' of

Closes #4355.

Note: See TracTickets for help on using tickets.