Re: discontiguous bounds ?

[Quincey Morris]

On May 8, 2016, at 22:32 , Miller Dale  wrote:
> 
> I wish to provide a facility with a NSTableView wherein the leftmost 
> (specifiable) columns remain statically on the left of the display (subject 
> to vertical scrolling) while the remaining columns scroll normally 
> constrained to the right of the static columns.

You mean the rightmost columns scroll *horizontally* I presume? And all the 
columns scroll vertically with their rows in sync?

> I'm not able to come up with a Cocoa implementation short of using two 
> separate NSTableView's with attendant bag-of-worms complexity.

AFAIK there’s nothing in Cocoa that will implement this for you. I’m not sure 
that using two table views is really very complex — they could potentially use 
the same data source and delegate — but the trick is to get the vertical 
scrolling in sync. I believe this is doable, though awkward. There’s even 
documentation:


https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/NSScrollViewGuide/Articles/SynchroScroll.html

but I warn you that this document was last updated in 2010, and the last time I 
tried to make sense of it I was pretty sure its sample code was confused and 
buggy.

> I'm not interested in a religious discussion about the Apple way of doing 
> things.

In this case, I don’t think there’s any religious aspect to it. What you want 
seems perfectly reasonable, but there just hasn’t been enough call for it for 
Apple to implement anything directly in NSTableView to make it easier.

The other direction to go would be to look at the current NSCollectionView 
capabilities (not the old NSCollectionView, but the functionality recently 
copied from UICollectionView). With suitable custom layout, you might be able 
to get this class to do what you’re trying to achieve. However, this is just 
speculation, I don’t have any specific knowledge about this.

___

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

discontiguous bounds ?

[Miller Dale]

I wish to provide a facility with a NSTableView wherein the leftmost  
(specifiable) columns remain statically on the left of the display  
(subject to vertical scrolling) while the remaining columns scroll  
normally constrained to the right of the static columns. I've done  
this successfully (and easily) on mainframe (ISPF) applications, but  
I'm not able to come up with a Cocoa implementation short of using two  
separate NSTableView's with attendant bag-of-worms complexity.
If I were wishing, I could wish for the ability to specify multiple  
discontiguous areas for the bounds of a view.

Am I missing something?
Please, I'm not interested in a religious discussion about the Apple  
way of doing things. This interface worked very well for me on the  
applications I created.

Thanks
Dale Miller
___

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: How to keep things alive in Arc?

[Quincey Morris]

On May 8, 2016, at 22:12 , Gerriet M. Denkmann  wrote:
> 
> Is there any other documentation (e.g. with a list of all __attribute__s and 
> their respective meaning)?

Documented here for ARC:

http://clang.llvm.org/docs/AutomaticReferenceCounting.html

If you search for “clang arc” this is always the top hit. For stuff other than 
ARC, go to clang.llvm.org and poke around using the links on the left.

___

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: How to keep things alive in Arc?

[Gerriet M. Denkmann]

> On 9 May 2016, at 09:25, Roland King  wrote:
> 
> 
>> On 9 May 2016, at 10:11, Gerriet M. Denkmann  wrote:
>> 
>> Thing *aThing = [ Thing new ];
>> 
>> void *thingData = [ aThing data ];   //  pointer to a buffer owned by 
>> aThing
>> 
>> … never use aThing after this point → Arc might release aThing right now
>> … but do lots of things with thingData
>> 
>> … no more need for thingData
>> [ aThing release];
>> 
>> How to prevent Arc to release aThing before I have done with thingData?
>> 
>> Gerriet.
>> 
> 
> 
> well [ aThing release ] won’t work in ARC, I assume you really mean aThing = 
> nil, or just letting aThing fall out of the bottom of the local scope
I meant: this was the code before I converted to Arc.

> either mark [ Thing data ] with NS_RETURNS_INNER_POINTER which is equivalent 
> to __attribute__((objc_returns_inner_pointer))

I did this, and now the app behaves again as it did before converting to Arc. 
No more data mutating behind my back and other strange effects.
Thanks a lot!

The only mention of this, which Xcode could find for me, was: Foundation 
Release Notes for OS X v10.8 and Earlier.
Is there any other documentation (e.g. with a list of all __attribute__s and 
their respective meaning)?


> or mark aThing with __attribute__((objc_precise_lifetime))
I think that NS_RETURNS_INNER_POINTER is more self explaining.


Kind regards,

Gerriet.


___

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: NSTableView is messaging zombie delegate

[Uli Kusterer]

On 08 May 2016, at 21:19, Matthew LeRoy  wrote:
> Unfortunately, setting the table view’s delegate to nil during tear-down 
> (either in -windowWillClose: or in NSViewController’s -dealloc) doesn’t seem 
> to fix the issue. I still get random but regularly reproducible crashes, with 
> the same stack trace.

Random ideas that may look similar:

1. -copy being called by the OS on a subclass of an AppKit class that you made 
(NSCells are popular for this), where you forgot to override -copyWithZone:
2. Random memory smasher (easily caused by manipulating UI from another thread)
3. Some MRC code in your ARC code over-releasing an object before it's even 
handed to NSViewController as a delegate.

… uh, can't think of anything else right now.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://stacksmith.org





___

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: How to keep things alive in Arc?

[Britt Durbrow]

Off of the top of my head, have a look at:

http://clang.llvm.org/docs/AutomaticReferenceCounting.html#precise-lifetime-semantics
 


and

http://clang.llvm.org/docs/AutomaticReferenceCounting.html#interior-pointers 



> On May 8, 2016, at 7:11 PM, Gerriet M. Denkmann  wrote:
> 
> Thing *aThing = [ Thing new ];
> 
> void *thingData = [ aThing data ];//  pointer to a buffer owned by 
> aThing
> 
> … never use aThing after this point → Arc might release aThing right now
> … but do lots of things with thingData
> 
> … no more need for thingData
> [ aThing release];
> 
> How to prevent Arc to release aThing before I have done with thingData?
> 
> Gerriet.
> 
> 
> 
> 
> ___
> 
> 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/bdurbrow%40rattlesnakehillsoftworks.com
> 
> This email sent to bdurb...@rattlesnakehillsoftworks.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: How to keep things alive in Arc?

[Roland King]

> On 9 May 2016, at 10:11, Gerriet M. Denkmann  wrote:
> 
> Thing *aThing = [ Thing new ];
> 
> void *thingData = [ aThing data ];//  pointer to a buffer owned by 
> aThing
> 
> … never use aThing after this point → Arc might release aThing right now
> … but do lots of things with thingData
> 
> … no more need for thingData
> [ aThing release];
> 
> How to prevent Arc to release aThing before I have done with thingData?
> 
> Gerriet.
> 


well [ aThing release ] won’t work in ARC, I assume you really mean aThing = 
nil, or just letting aThing fall out of the bottom of the local scope

either mark [ Thing data ] with NS_RETURNS_INNER_POINTER which is equivalent to 
__attribute__((objc_returns_inner_pointer))

or mark aThing with __attribute__((objc_precise_lifetime))



___

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

How to keep things alive in Arc?

[Gerriet M. Denkmann]

Thing *aThing = [ Thing new ];

void *thingData = [ aThing data ];  //  pointer to a buffer owned by 
aThing

… never use aThing after this point → Arc might release aThing right now
… but do lots of things with thingData

… no more need for thingData
[ aThing release];

How to prevent Arc to release aThing before I have done with thingData?

Gerriet.




___

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: NSTableView is messaging zombie delegate

[Quincey Morris]

On May 8, 2016, at 12:19 , Matthew LeRoy  wrote:
> 
> Unfortunately, setting the table view’s delegate to nil during tear-down 
> (either in -windowWillClose: or in NSViewController’s -dealloc) doesn’t seem 
> to fix the issue. I still get random but regularly reproducible crashes, with 
> the same stack trace.
> 
> Any other ideas?

It’s the right idea, but you should cast your net a bit wider.

If you look at your backtrace again, you’ll see that it crashed doing something 
with rows. It’s as likely trying to message your data source as your delegate. 
You should nil that as well. Note that it’s not necessarily that any particular 
object has or hasn't been deallocated, but there’s a whole network of objects 
that may have now-invalid references somewhere. (In this case, it looks like 
the reference to a table cell view that’s crashing.)

Also consider delegate (and similar) references to view controllers and window 
controllers. IIRC, the window itself may not be deallocated immediately after 
being closed, because it’s kept alive until the window server (a difference 
process) gets around to cleaning up after it, and so it might take a few 
iterations of your run loop before the window object goes away. That in turn 
might keep alive other controller/delegate objects that your app has otherwise 
finished with.

The trick to solving this is to find just the right weak reference to nil.

The other area to pay attention to is the possibility that you’ve created some 
other retain cycles between objects that keep them alive longer than necessary. 
That may in turn cause them to follow now-invalid weak references.


___

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: NSTableView is messaging zombie delegate

[Jens Alfke]

> On May 8, 2016, at 12:19 PM, Matthew LeRoy  wrote:
> 
> Unfortunately, setting the table view’s delegate to nil during tear-down 
> (either in -windowWillClose: or in NSViewController’s -dealloc) doesn’t seem 
> to fix the issue. I still get random but regularly reproducible crashes, with 
> the same stack trace.

Sounds like the delegate is being dealloced before either of those two methods 
is called. Set a breakpoint in its dealloc method (create a stub dealloc if 
necessary) to figure out why.

I assume you’ve also enabled NSZombie in the scheme’s diagnostics tab?

—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: NSTableView is messaging zombie delegate

[Matthew LeRoy]

>On May 6, 2016, at 1:03 PM, Matthew LeRoy  wrote:
>
>   My understanding is that NSTableView's delegate is a zeroing weak 
> reference
>
>
>Are you sure? Historically it’s been unsafe_unretained — in the old days 
>before weak references or ARC, the view never retained nor released the 
>delegate. The type of crash you’re having was a not-uncommon bug.
>
>Apple may have upgraded the property to a proper zeroing weak reference, but I 
>can’t tell from the docs. They simply say "In a managed memory environment, 
>the table view maintains a weak reference to the delegate (that is, it does 
>not retain the delegate).”
> I’m assuming ARC counts as “managed”, but that sentence does not include the 
> word “zeroing”…
>
>I would play it safe and explicitly set the table view’s delegate to nil when 
>tearing down the window. I usually do this in the windowWillClose delegate 
>method.
>
>—Jens

Good point. I had been doing so much reading about delegates, weak and zeroing 
weak references, I failed to notice that the docs (and NSTableView.h) only say 
“weak reference” — no “zeroing”.

Unfortunately, setting the table view’s delegate to nil during tear-down 
(either in -windowWillClose: or in NSViewController’s -dealloc) doesn’t seem to 
fix the issue. I still get random but regularly reproducible crashes, with the 
same stack trace.

Any other ideas?

Matt

___

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