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.  
Ordered-out windows /can/ occasionally be seen on screen (consider App Exposé, 
which shows minimized windows, or Show All Tabs in apps using NSWindow 
tabbing), and the system may snapshot or display ordered-out windows for 
various reasons at other times, too.
In general, I’d say: you should not /rely/ on the fact that ordered-out windows 
are displayed—in the future, the system might choose to defer it as an 
optimization—but neither should you expect it not to happen.
Simply bailing out of -drawRect: (which, incidentally, is called on /views/, 
not windows) seems like a bad idea, since the window may display into an 
invalid state, which could result in corruption.  I’d instead investigate the 
underlying cause of the crash, which may result from your view attempting to 
use an object that it does not hold a strong (or weak-upgraded-to-strong) 
reference to.


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.  But I can be more precise about when I 
decline to draw, by having my document post a notification when it starts to 
shut down.



If it’s a C++ object then reference it in your view with a weak_ptr so 
you can tell when/if it has been disposed of.



Oh, cool!  I didn't get around to using C++11 until about a year ago 
(yes, I'm behind the curve), and I read a number of "what's new in 
C++11" web pages, but somehow I missed std::weak_ptr.




On Dec 13, 2018, at 10:44 AM, James Walker mailto:jam...@frameforge3d.com>> wrote:

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 calling 
CA::Transaction::commit() resulting in -[NSWindow displayIfNeeded] being 
called, but I don't know why displayIfNeeded would do anything with an 
invisible window.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com

This email sent to petr...@mac.com




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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 all of its windows have been closed and 
released.
It’s been many years since I used NSDocument, but it sounds like you shouldn’t 
be deleting this C++ object when the document is being closed; wait until it’s 
dealloced.

—Jens

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSString drawAtPoint in Mojave

2018-12-13 Thread Tom Doan 
ITOT that the problem was that I had a call to lockFocusIfCanDraw 
in my drawRect handler (from who knows what prior incarnation of 
the OS) which, according to the documentation is deprecated and 
"does nothing and should not be called". The second half of that is 
probably correct, the first half isn't. In the 10.14 SDK, it changed the 
[NSGraphicsContext currentContext] so my text was apparently 
being drawn to nowheresville. Works fine with the 10.13 SDK.


> I just started testing a port of my application to Mojave. I'm having
> a rather odd problem with NSString drawAtPoint withAttributes. I use
> that to add text to graph windows. All the lines and fills look fine,
> but the text, done with drawAtPoint, doesn't show on the screen.
> However, if I take the window and create a PDF from it, everything
> looks fine. It also works fine on High Sierra. Anybody have any idea
> what might be going wrong with this?
> 
> Best regards,
> 
> Tom Doan
> ---
> Estima
> 1560 Sherman Ave #1029
> Evanston, IL 60201
> USA
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/tomd%40estima.com
> 
> This email sent to t...@estima.com


---
1560 Sherman Ave #1029
Evanston, IL 60201
USA


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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 windows, or Show All Tabs in apps 
using NSWindow tabbing), and the system may snapshot or display 
ordered-out windows for various reasons at other times, too.


In general, I’d say: you should not /rely/ on the fact that ordered-out 
windows are displayed—in the future, the system might choose to defer it 
as an optimization—but neither should you expect it not to happen.


Simply bailing out of -drawRect: (which, incidentally, is called on 
/views/, not windows) seems like a bad idea, since the window may 
display into an invalid state, which could result in corruption.  I’d 
instead investigate the underlying cause of the crash, which may result 
from your view attempting to use an object that it does not hold a 
strong (or weak-upgraded-to-strong) reference to.


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.  But I can be more 
precise about when I decline to draw, by having my document post a 
notification when it starts to shut down.


Thanks for the reply.

On Dec 13, 2018, at 10:44 AM, James Walker > wrote:


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 calling CA::Transaction::commit() resulting 
in -[NSWindow displayIfNeeded] being called, but I don't know why 
displayIfNeeded would do anything with an invisible window.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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 NSWindow 
tabbing), and the system may snapshot or display ordered-out windows for 
various reasons at other times, too.

In general, I’d say: you should not rely on the fact that ordered-out windows 
are displayed—in the future, the system might choose to defer it as an 
optimization—but neither should you expect it not to happen.

Simply bailing out of -drawRect: (which, incidentally, is called on views, not 
windows) seems like a bad idea, since the window may display into an invalid 
state, which could result in corruption.  I’d instead investigate the 
underlying cause of the crash, which may result from your view attempting to 
use an object that it does not hold a strong (or weak-upgraded-to-strong) 
reference to.

Matt

> On Dec 13, 2018, at 10:44 AM, James Walker  wrote:
> 
> 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 calling 
> CA::Transaction::commit() resulting in -[NSWindow displayIfNeeded] being 
> called, but I don't know why displayIfNeeded would do anything with an 
> invisible window.
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/matthew_jacobson%40apple.com
> 
> This email sent to matthew_jacob...@apple.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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 calling CA::Transaction::commit() resulting in -[NSWindow 
displayIfNeeded] being called, but I don't know why displayIfNeeded 
would do anything with an invisible window.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Custom NSButton image effects for pressed/disabled

2018-12-13 Thread Richard Charles 

> On Dec 12, 2018, at 5:31 PM, Lars C. Hassing  wrote:
> 
> The button should look like
> 
> +---+ +---+
> | 1 |  Title  | 2 |
> +---+ +—+
> 
> (try using Courier for the ASCII art)
> 
> I am looking for system functions to produce the SAME look and feel as Cocoa 
> controls.

Compose your image as a single image but with disjointed parts. I use Inkscape 
to draw vector graphics and use a pdf for the image. The only place in the 
"image" where there is something is where something is drawn. Everywhere else 
it is just an empty background.

--Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Custom NSButton image effects for pressed/disabled

2018-12-13 Thread Alastair Houghton 
On 12 Dec 2018, at 01:03, Lars C. Hassing  wrote:
> 
> If I assign an image to an NSButton it is displayed with nice pressed and 
> disabled effects.
> 
> In my custom NSButton, that should display image1+title+image2, I override 
> drawRect:, but how do I obtain the EXACT SAME system effects for the two 
> images?

Override -drawRect: to call the cell’s -drawWithFrame:inRect: *twice*, once 
with the cell’s image set to image1 and the alignment set to left, and once 
with the cell’s image set to image2 and the alignment set to right, making sure 
to clip appropriately so it only draws the portions you want. Obviously your 
custom button is going to have its own “image1” and “image2” properties, right, 
so you don’t care that the “image” property is all over the place :-)

e.g. on the first call, draw this:


.+---+ .
.| 1 |  Title  .
.+---+ .


Then on the second call, add this part:

   ...
 +---+ .+---+.
 | 1 |  Title  .| 2 |.
 +---+ .+---+.
   ...

Do note that if you take this approach, you’re relying on controls being 
NSCell-based. At some point in the future, I think that’s likely to change, at 
which point you might need to do something else.

It’s also conceivable that this might work better on current versions of the 
macOS if you made a custom NSButtonCell subclass and did the clipping and two 
calls in that. Why? Because various controls currently try to detect whether 
they’re using a custom cell or not and use different rendering code if they are 
not…

> I am looking for system functions to produce the SAME look and feel as Cocoa 
> controls.
> 
> Motif, Windows and Carbon all have system functions to draw control parts in 
> various states
> to help developers achieve a consistent look and feel, why wouldn’t Cocoa be 
> interested in supporting that?


Cocoa does in fact have this kind of functionality internally, but it’s 
currently SPI rather than API. I’m not sure whether Apple intends to expose the 
theme support at some time in the future.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com