Ticket #14651 (closed defect: fixed)

Opened 9 months ago

Last modified 7 months ago

wxTipWindow on OSX pops up and gets stuck

Reported by: cozmotion Owned by:
Priority: normal Milestone:
Component: wxOSX-Cocoa Version: 2.9-svn
Keywords: Cc:
Blocked By: Patch: no
Blocking:

Description

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

wizardtipwindowsampleapp.patch download (4.6 KB) - added by cozmotion 9 months ago.
patch for sample wizard.cpp
wizardtipwindowsampleapp.cpp download (19.2 KB) - added by cozmotion 9 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 9 months ago.

Change History

Changed 9 months ago by cozmotion

patch for sample wizard.cpp

Changed 9 months ago by cozmotion

complete .cpp for my sample

Changed 9 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 9 months ago by cozmotion

Changed 9 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.

Changed 7 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...

Changed 7 months ago by VZ

  • status changed from confirmed to closed
  • resolution set to fixed

(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.