#14651 closed defect (fixed)

wxTipWindow on OSX pops up and gets stuck

Reported by: cozmotion Owned by:
Priority: normal Milestone:
Component: wxOSX-Cocoa 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 23 months ago.
patch for sample wizard.cpp
wizardtipwindowsampleapp.cpp download (19.2 KB) - added by cozmotion 23 months ago.
complete .cpp for my sample
Screen Shot 2012-09-12 at 3.44.58 PM.png download (97.3 KB) - added by cozmotion 23 months ago.

Download all attachments as: .zip

Change History (7)

Changed 23 months ago by cozmotion

patch for sample wizard.cpp

Changed 23 months ago by cozmotion

complete .cpp for my sample

comment:1 Changed 23 months 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 23 months ago by cozmotion

comment:2 Changed 23 months 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 21 months 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 21 months 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.