NSNotification coalescing - which one gets through?

I am trying to work out whether there are any rules that define which of multiple NSNotifications combined using coalescing actually get through to the receivers, and preferably a way of controlling that behaviour. This becomes relevant if for example there is different UserInfo associated with

Re: NSNotification coalescing - which one gets through?

Actually I think I may have answered my own question: calling dequeueNotificationsMatching immediately before posting a new notification seems to do the trick. This seems like a reasonable and logical way of achieving what I want. Can anyone see any problem with doing that? On 6 May 2015, at 11

Grabbing window - The contents of this window cannot be shared

Hi all, I have developed an app with an NSWindow containing a NSScrollView subclass for the document window. When I ry to grab this window with Grab.app for documentation purposes, Grab.app tells me The window could not be captured The contents of this window cannot be shared I

Re: Grabbing window - The contents of this window cannot be shared

On 06 May 2015, at 14:09, Andreas Höschler wrote: > Hi all, > > I have developed an app with an NSWindow containing a NSScrollView subclass > for the document window. When I ry to grab this window with Grab.app for > documentation purposes, Grab.app tells me > > The window could not be c

Re: Help: NSScrollView is resizing its documentView down to (0, 0)

On 05 May 2015, at 18:26, Jens Alfke wrote: > I haven't done much AppKit work in a while. Right now I have a small app > where I'm trying to do something very simple: put a custom NSView in a window > and make it scrollable. The view determines its own frame size based on the > content it needs

Re: Help: NSScrollView is resizing its documentView down to (0, 0)

On 06 May 2015, at 03:21, Jens Alfke wrote: >> Constrain your view to the top, right and left of the clipview but not the >> bottom. I have never had to do this. What are you trying to fix with this? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple

Re: Help: NSScrollView is resizing its documentView down to (0, 0)

> On 6 May 2015, at 23:39, Uli Kusterer wrote: > > On 06 May 2015, at 03:21, Jens Alfke > wrote: >>> Constrain your view to the top, right and left of the clipview but not the >>> bottom. > > I have never had to do this. What are you trying to fix with this? The

Re: Help: NSScrollView is resizing its documentView down to (0, 0)

> On 06 May 2015, at 17:41, Roland King wrote: > > >> On 6 May 2015, at 23:39, Uli Kusterer wrote: >> >> On 06 May 2015, at 03:21, Jens Alfke > > wrote: Constrain your view to the top, right and left of the clipview but not the bottom. >> >> I have neve

iOS firing an event in the future when an app is in the background

iOS 7/8, Xcode 6.2 I'm looking into performing an event in the future on iOS very likely when the app may be in the background, possibly up to 24 hours in the future. I'm looking at using an NSTimer, performSelectorAfterDelay, or GDC's dispatch_after. Looking at all the caveats for background

Re: iOS firing an event in the future when an app is in the background

> On 7 May 2015, at 00:08, Alex Zavatone wrote: > > iOS 7/8, Xcode 6.2 > > I'm looking into performing an event in the future on iOS very likely when > the app may be in the background, possibly up to 24 hours in the future. > > I'm looking at using an NSTimer, performSelectorAfterDelay, or G

Re: Help: NSScrollView is resizing its documentView down to (0, 0)

> On May 6, 2015, at 8:36 AM, Uli Kusterer wrote: > > So you're not setting a constraint on the *document* view? How do you expect > it to know how to constrain that view otherwise? The size of the document view is fundamentally unrelated to the size of the clip or scroll view — the whole poi

Re: iOS firing an event in the future when an app is in the background

> On May 6, 2015, at 9:08 AM, Alex Zavatone wrote: > > I'm looking into performing an event in the future on iOS very likely when > the app may be in the background, possibly up to 24 hours in the future. Keep in mind that your app isn’t even running when it’s in the background on iOS. It’s n

Re: NSNotification coalescing - which one gets through?

On May 6, 2015, at 3:54 AM, Jonathan Taylor wrote: > I am trying to work out whether there are any rules that define which of > multiple NSNotifications combined using coalescing actually get through to > the receivers, and preferably a way of controlling that behaviour. This > becomes releva

static analyzers says I'm leaking, I _think_ I'm not

I've had problems in the past where I failed to understand the Cocoa ownership conventions, I'm willing to grant that could be the case. I know for sure that the analyzer enforces the naming conventions, that is, the exact same function names in C or C++ won't yield that same warnings as "alloc",

Re: static analyzers says I'm leaking, I _think_ I'm not

> On May 6, 2015, at 1:57 PM, Michael David Crawford > wrote: > > // LifeGrid.h > @property (assign, nonatomic) GridCycler *cycler; > > // Lifegrid.m - init > self.cycler = [[GridCycler alloc] initWithGrid: self]; // Potential > leak of an object > if ( nil == self.cycler ) goto cycler_failed

Re: static analyzers says I'm leaking, I _think_ I'm not

This is 6.2. I speculated a different diagnostic was a bug; were it correct, I would have seen that same diagnostic on some other code. I'll file a radar with a minimal test case if you'd like me to. I'll download 6.3.1 right now. Michael David Crawford, Consulting Software Engineer mdcrawf...@g

Re: static analyzers says I'm leaking, I _think_ I'm not

> On May 6, 2015, at 2:17 PM, Michael David Crawford > wrote: > > This is 6.2. I speculated a different diagnostic was a bug; were it > correct, I would have seen that same diagnostic on some other code. > > I'll file a radar with a minimal test case if you'd like me to. > > I'll download 6.

Re: static analyzers says I'm leaking, I _think_ I'm not

On May 6, 2015, at 3:57 PM, Michael David Crawford wrote: > // LifeGrid.h > @property (assign, nonatomic) GridCycler *cycler; > > // Lifegrid.m - init > self.cycler = [[GridCycler alloc] initWithGrid: self]; // Potential > leak of an object > if ( nil == self.cycler ) goto cycler_failed; > > /

Re: static analyzers says I'm leaking, I _think_ I'm not

> On May 6, 2015, at 1:57 PM, Michael David Crawford > wrote: > I've had problems in the past where I failed to understand the Cocoa > ownership conventions, I'm willing to grant that could be the case. > > I know for sure that the analyzer enforces the naming conventions, > that is, the exact s

Re: static analyzers says I'm leaking, I _think_ I'm not

John McCall wrote: > You should probably make the property readonly and just directly assign to > the ivar in -init. That works. In this particular case, it might make more sense for my property to be just a regular ivar, without a getter and setter. That is, my grid object owns a cycler objec

Re: static analyzers says I'm leaking, I _think_ I'm not

If the property is set to "retain", then the line self.cycler = [[[….initWithGrid:self] autorelease] will cause the setter to retain the passed in object, so after this line, _cycler will have a (heuristic) retain count of 2 (an alloc and a retain). After this, when the autorelease pool is drai

Re: static analyzers says I'm leaking, I _think_ I'm not

On May 6, 2015, at 4:40 PM, Aaron Montgomery wrote: > If the property is set to "retain", then the line > > self.cycler = [[[….initWithGrid:self] autorelease] > > will cause the setter to retain the passed in object, so after this line, > _cycler will have a (heuristic) retain count of 2 (an a

Re: static analyzers says I'm leaking, I _think_ I'm not

I agree that it's inappropriate to expect that the analyzer will assume that the getters and setters work the way they conventionally do. One reason we have properties is so that, when required, they can do other things: - (void) setAdversary: (int)enemy { _enemy = enemy; [_enemy setUpTh

Re: Help: NSScrollView is resizing its documentView down to (0, 0)

On Wed, May 6, 2015 at 11:54 AM, Jens Alfke wrote: > > > On May 6, 2015, at 8:36 AM, Uli Kusterer > wrote: > > > > So you're not setting a constraint on the *document* view? How do you > expect it to know how to constrain that view otherwise? > > The size of the document view is fundamentally un