Re: Why would a view be asked to draw after its window has been ordered out?

2018-12-13 Thread James Walker
On 12/13/18 1:35 PM, Rob Petrovec wrote: On Dec 13, 2018, at 2:26 PM, James Walker wrote: On 12/13/18 11:05 AM, Matt Jacobson wrote: The buffered nature of the Mac OS X window system means that windows can “display” (i.e., go through the process of updating) even when ordered out.

Re: Why would a view be asked to draw after its window has been ordered out?

2018-12-13 Thread Jens Alfke
> On Dec 13, 2018, at 1:26 PM, James Walker wrote: > > The view was using a C++ object that had been destroyed during closing of my > document. I'm afraid that if I start playing with the order of destruction, > I'm likely to break something else. An NSDocument won’t be dealloced until

Re: Why would a view be asked to draw after its window has been ordered out?

2018-12-13 Thread James Walker
On 12/13/18 11:05 AM, Matt Jacobson wrote: The buffered nature of the Mac OS X window system means that windows can “display” (i.e., go through the process of updating) even when ordered out.  Ordered-out windows /can/ occasionally be seen on screen (consider App Exposé, which shows minimized

Re: Why would a view be asked to draw after its window has been ordered out?

2018-12-13 Thread Matt Jacobson
The buffered nature of the Mac OS X window system means that windows can “display” (i.e., go through the process of updating) even when ordered out. Ordered-out windows can occasionally be seen on screen (consider App Exposé, which shows minimized windows, or Show All Tabs in apps using

Why would a view be asked to draw after its window has been ordered out?

2018-12-13 Thread James Walker
I was getting a crash on quit resulting from a drawRect: method being called on a window that had been ordered out. I can solve the immediate problem just by bailing out of drawRect: if the window is invisible, but I wish I understood what's going on. The call stack shows a run loop observer