Re: Confusion with copyWithZone and Archiving

[Graham Cox]

> On 1 Mar 2016, at 10:24 AM, Doug Hill  wrote:
> 
> Given the amount of private implementation in NSView, my guess is that 
> copying an NSView yourself without super support would be 
> difficult/impossible in practice. However, I would be interested in others 
> with more information to give an opinion.


Agreed, and the need to copy something designed to be uncopyable in general may 
be a code smell. It might be a case that the view in question should ‘have a’ 
whatever copyable thingamajig instead of being subclassed to ‘be a’ 
thingamajig. In the few cases where copying views is legitimate (I can think of 
one case where I programatically created a stack of views based on a series of 
templates - but that was before NSViewController existed and that would 
probably be the right solution now) you can use the archive/dearchive solution 
to copy a view. Alternatively, it might be enough to create a view as part of a 
copy and only use basic properties such as its frame to define the copied one. 
If it has subviews though… ugh.

G.
___

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

Is Core Data / NSAtomicStore only for data objects with IDs?

[Daryle Walker]

OK, I’m about to write a cool app. I’m thinking of using Core Data to handle 
the, well, data. I’ve been looking around for weeks on how to use NSAtomicStore 
to read/write data in “legacy formats.” I finally saw a guide by Apple today 
(referenced from the API page for NSAtomicStore). The classes assume you’ll be 
generating some ID data for your various nodes. My data is dumb; it has no 
database-ish IDs anywhere to use. I can’t just make up random UUIDs because the 
lookups have to be reversible and the format is too dumb to place any IDs. Does 
this mean that my quest has been for nothing, that I can’t use CoreData to 
directly serialize to/from my format?

I just said “directly” because I can still make a data model for my format. I 
just have to strip out any IDs when I serialize it to users. I can keep any 
internal IDs when I store object graphs in my app’s library folders. Of course, 
I can’t directly read in the format either; I have to read the data in 
separately, create a blank object graph, import the data in, and keep track of 
both the graph and original file’s URL when I need to save out (I’ll just 
export the graph to a new ID-less file and swap.).

The guide mentioned HTML and CSV examples, but didn’t show any. HTML I can 
understand; you can use something like DOM to address every node. I can’t see 
it with CSV, unless you use one of the fields to make an ID. Is that what Apple 
meant, or can you use Core Data with dumb, un-ID’d data?

(I can understand the “use NSIncrementalStore for Internet-based stores” claims 
too. The main database’s URL serves as the store’s ID, and the inner objects 
and attributes can be represented by sub-URLs and/or index paths.)

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT 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: Confusion with copyWithZone and Archiving

[Doug Hill]

> On Feb 29, 2016, at 2:37 PM, Graham Cox  wrote:
> 
> 
>> On 1 Mar 2016, at 1:58 AM, Dave  wrote:
>> 
>> @interface LTWBaseClass : NSView 
> 
> 
>> Do I need to call the super version of this method too?
> 
> 
> 
> In general, yes. But NSView doesn’t conform to NSCopying, so there is no 
> super to call. You’ll have to do all of the copying needed to copy the 
> underlying view.

Given the amount of private implementation in NSView, my guess is that copying 
an NSView yourself without super support would be difficult/impossible in 
practice. However, I would be interested in others with more information to 
give an opinion.

Doug Hill
___

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: Confusion with copyWithZone and Archiving

[Graham Cox]

> On 1 Mar 2016, at 1:58 AM, Dave  wrote:
> 
> @interface LTWBaseClass : NSView 


> Do I need to call the super version of this method too?



In general, yes. But NSView doesn’t conform to NSCopying, so there is no super 
to call. You’ll have to do all of the copying needed to copy the underlying 
view.



___

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: Confusion with copyWithZone and Archiving

[Dave]

Thanks Doug, I was looking in the wrong place!

All the Best
Dave

___

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: Triggering UITableView's -didSelectRowAtIndexPath: delegate callback

[Keary Suska]

> On Feb 28, 2016, at 11:05 PM, Jens Alfke  wrote:
> 
> 
>>> On Feb 27, 2016, at 4:27 PM, Keary Suska 
>>> > wrote:
>>> 
>>>  This results in a much more reliable and extensible decoupling since no 
>>> other object should know those internal signaling mechanics and should have 
>>> confidence that any other object interested in the selection will be 
>>> dutifully notified. In fact, this is how NSTableView works. Why UITableView 
>>> doesn’t, seems worthy of a radar.
> 
> NSTableView doesn’t work that way. Changing the selection programmatically 
> does not trigger a selection-changed notification / delegate callback.

That does appear to be the case, at least almost entirely. I was 
mis-remembering as curiously, -tableViewSelectionDidChange: is always sent, 
perhaps simply a side effect to the promise of notifications, but in contrast 
-tableViewSelectionIsChanging: is not. Looking at my older code I did notice 
that I needed to work around -selectionShouldChangeInTableView: not being 
called when I hoped it would.

I stand by my assertion that delegate methods should always be called 
regardless of whether the triggering event is from the UI or programmatically, 
and that the fact they don’t has nothing to do with decoupling but instead an 
implementation decision.

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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: Confusion with copyWithZone and Archiving

[Doug Hill]

From the NSCopying protocol reference:

If a subclass inherits NSCopying from its superclass and declares additional 
instance variables, the subclass has to override copyWithZone: to properly 
handle its own instance variables, invoking the superclass’s implementation 
first.

There are many other good tidbits of info in there, check it out and hopefully 
it will cover what you want to know.

Doug Hill


> On Feb 29, 2016, at 6:58 AM, Dave  wrote:
> 
> Hi,
> 
> I have an inheritance chain Classes that are NSCoding and NSCopying compliant 
> like so:
> 
> 
> @interface LTWBaseClass : NSView 
> 
> @interface LTWSubclassA : LTWBaseClass 
> 
> @interface LTWSubclassB : LTWSubclassA 
> 
> Each of these three classes contain properties that need to be archived and 
> unarchived. In initWithCoder and encodeWithCoder methods I call [super 
> initWithCoder] and  [super encodeWithCoder], but I’m not sure what to do for 
> copyWithZone? Do I need to call the super version of this method too?
> 
> Thanks a lot, All the Best
> Dave
___

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

Confusion with copyWithZone and Archiving

[Dave]

Hi,

I have an inheritance chain Classes that are NSCoding and NSCopying compliant 
like so:


@interface LTWBaseClass : NSView 

@interface LTWSubclassA : LTWBaseClass 

@interface LTWSubclassB : LTWSubclassA 

Each of these three classes contain properties that need to be archived and 
unarchived. In initWithCoder and encodeWithCoder methods I call [super 
initWithCoder] and  [super encodeWithCoder], but I’m not sure what to do for 
copyWithZone? Do I need to call the super version of this method too?

Thanks a lot, All the Best
Dave


___

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