Opened 7 years ago

Closed 5 years ago

#12865 closed defect (fixed)

wxWindow::Freeze/Thaw is not implemented for wxOSX/Cocoa

Reported by: gevorg Owned by: csomor
Priority: normal Milestone: 2.9.5
Component: wxOSX Version: stable-latest
Keywords: window freeze thaw cocoa Cc:
Blocked By: Blocking:
Patch: no


In src/osx/window_osx.cpp, wxWindowMac::DoFreeze() and wxWindowMac::DoThaw() implementations are conditioned on #if wxOSX_USE_CARBON
Unfortunately I am not familiar with Cocoa API otherwise I would try to make a patch for this.
Any help is much appreciated!

Change History (11)

comment:1 Changed 7 years ago by csomor

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

comment:2 Changed 5 years ago by vadz

  • Milestone set to 2.9.5

Could you please retest with r72924?

P.S. Setting milestone just to not forget to close it soon if it does work as expected.

comment:3 Changed 5 years ago by johnr

At the risk of later being proven wrong, freeze/thaw works a treat for me when tested on a modal dialog.

I do get a crash without an an assert if thaw count > freeze count.

2012-11-10 16:39:19.121 Myexe[72969:707] * Assertion failure in -[NSWindowGraphicsContext reenableFlush], /SourceCache/AppKit/AppKit-1138.47/GraphicsContext.subproj/NSWindowGraphicsContext.m:170
2012-11-10 16:39:19.122 Myexe[72969:707] Invalid parameter not satisfying: _flushDisableCount > 0

comment:4 follow-up: Changed 5 years ago by vadz

I don't understand how is this possible, DoThaw() shouldn't be called more times than DoFreeze() because of the checks in wxWindowBase::Freeze() and Thaw(). Do you have some simple way to reproduce the problem?

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

Replying to vadz:

Do you have some simple way to reproduce the problem?

No. I can only assume I didn't fully clean before building the wxWidgets build I was using when I saw the crash. After a clean and rebuild I could not reproduce it using all the permutations I could think of including freezing parent and children separately and in combination and in or out of event handlers. Probably explains the html help artifact I saw as well.

This ticket be closed as far as I can see.

comment:6 Changed 5 years ago by vadz

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

comment:7 Changed 5 years ago by disc

  • Resolution fixed deleted
  • Status changed from closed to reopened

I'm seeing the same assert when starting the Widgets sample with r72924 but not with r72923. Tested on OS X 10.8.2 (Xcode 4) and 10.6.8 (Xcode 3) using ../configure --enable-debug --with-cocoa .

comment:8 Changed 5 years ago by csomor

very strange, in OnPageChanged a wxWindowUpdateLocker is set onto the current page (->freeze is called), onto that page now the new content is added, leaving the scope Thaw is called, but not only on the locked page, but also on all the newly added elements - which never had been frozen before - how is this supposed NOT to trigger incorrect thaws ?

comment:9 Changed 5 years ago by vadz

I see 2 solutions:

  1. Implicitly freeze any children created with a frozen parent.
  2. Remember the current children when freezing the parent and thawing only those when the parent is thawed.

The second one seems to be more complicated and less useful, so if the first can be implemented for wxOSX, it would probably be best.

comment:10 Changed 5 years ago by csomor

  • Status changed from reopened to accepted

ok, answer to self: Freeze is set correctly in AddChild, but at this moment the OSX control does not exist yet, therefore no native freeze is executed, I'll have to cover that ...

comment:11 Changed 5 years ago by SC

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

(In [72988]) implementing delayed freezing, fixes #12865

Note: See TracTickets for help on using tickets.