Opened 6 years ago

Closed 6 years ago

#14651 closed defect (fixed)

wxTipWindow on OSX pops up and gets stuck

Reported by: cozmotion Owned by:
Priority: normal Milestone:
Component: wxOSX Version: stable-latest
Keywords: Cc:
Blocked By: Blocking:
Patch: no


Apologies in advance - I am not too clear on how to submit a ticket though I did read the howto.

This occurs when it is in a wxPanel in a WizardPageSimple though the problem is different when it is simply in a wxPanel.

In my patched wizard sample, when you mouseover the "buoy" you get an assertion. Separately I have worked-around that, and then you can see that once the tipwindow goes up, the Panel is no longer getting mouse events -- until you click in the panel.

...In a wxPanel, the assertions are still thrown, but mouse events do not go away.

I am using 2.9.4 and cocoa.

wxUSE_POPUPWIN is set to 1 in my build

The same code runs fine on Windows with 2.9.3

Attachments (3)

wizardtipwindowsampleapp.patch download (4.6 KB) - added by cozmotion 6 years ago.
patch for sample wizard.cpp
wizardtipwindowsampleapp.cpp download (19.2 KB) - added by cozmotion 6 years ago.
complete .cpp for my sample
Screen Shot 2012-09-12 at 3.44.58 PM.png download (97.3 KB) - added by cozmotion 6 years ago.

Download all attachments as: .zip

Change History (7)

Changed 6 years ago by cozmotion

patch for sample wizard.cpp

Changed 6 years ago by cozmotion

complete .cpp for my sample

comment:1 Changed 6 years ago by vadz

The patch looks fine, thanks (and the entire modified sample is not really necesary) but could you please also indicate which assert are we speaking about here? I.e. where is it exactly in the sources?

Also, is it really related to wxWizard? I.e. does it work correctly if you do exactly the same thing for a wxPanel in a normal wxFrame?

Changed 6 years ago by cozmotion

comment:2 Changed 6 years ago by cozmotion

I attached a screenshot of the assertion dialog.

In a wxPanel in just a wxFrame, you do get the assertions, but you do not lose the mouse events. That happens in the wizard page only, as far as I have seen.

comment:3 Changed 6 years ago by vadz

  • Status changed from new to confirmed

There seems to be something wrong with focus events under OS X as Show(false) send wxEVT_KILL_FOCUS to the window being closed there but apparently not elsewhere. I'll work around this in wxTipWindow for now but the real problem is somewhere deeper...

comment:4 Changed 6 years ago by VZ

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

(In [72813]) Avoid double destruction of wxTipWindow under wxOSX.

Hiding the window results in wxEVT_KILL_FOCUS under OS X and this destroys it
already, so when we call Destroy() from wxTipWindow::Close() later, it
triggers assert about destroying it twice.

Avoid doing this under OS X for now, even though the real problem is probably
the discrepancy in wxEVT_KILL_FOCUS event generation under different platforms.

Closes #14651.

Note: See TracTickets for help on using tickets.