On Sun, Feb 16, 2014, at 05:17 PM, Jerry Krinock wrote:
> Don’t. Use Core Data.
Remove the period between "Don't" and "Use", and your sentence is
correct.
Core Data isn't a solution. Removing bindings is the solution.
--Kyle Sluder
___
Cocoa-dev ma
On 2014 Feb 16, at 08:34, Trygve Inda wrote:
> I have an NSTableView with several columns bound to an NSArrayController
> which manages the array of my custom objects.
>
> How is the best way to do this?
Don’t. Use Core Data. Core Data will do it.
__
On 17 Feb 2014, at 3:34 am, Trygve Inda wrote:
> How is the best way to do this?
>
> Since the table uses bindings, the setting of the property is handed by the
> binding system.
One way to handle this is illustrated in Hillegasse's classic book on Cocoa.
I'm looking at the 2nd edition, not
On Feb 16, 2014, at 10:22, Kevin Meaney wrote:
>
> On 16 Feb 2014, at 17:06, Jens Alfke wrote:
>
>> On Feb 16, 2014, at 5:27 AM, Kevin Meaney wrote:
>>
>>> Is the only reason for interoperability with manual retain-release code?
>>
>> For backward compatibility. Nearly every piece of exist
On Feb 16, 2014, at 9:34 AM, Trygve Inda wrote:
> I have an NSTableView with several columns bound to an NSArrayController
> which manages the array of my custom objects.
>
> Undo of course works while editing a cell in the NSTableView, but once the
> edit is complete, I need to manage it myself.
On Feb 16, 2014, at 1:03 PM, Jens Alfke wrote:
> On Feb 16, 2014, at 10:22 AM, Kevin Meaney wrote:
>
>> I didn't say take them out. I said why do they need to return an
>> autoreleased object. Why can't they just return an object like alloc init...
>> does.
>
> Because if they returned an obj
And would be just like every other manual reference-counting scheme, with all
of the additional code they entail, and the higher liklihood of bugs, and so
on...
On Feb 16, 2014, at 2:13 PM, Jens Alfke wrote:
> The only way to resolve this without autorelease would be to enforce that
> _all_ m
On Feb 16, 2014, at 10:22 AM, Kevin Meaney wrote:
> You're missing the question I was trying to ask. Why is autorelease needed at
> all?
It's needed when a method creates an object [or otherwise gets an object with a
reference that needs to be released] and has to return that object, but the
On Feb 16, 2014, at 10:22 AM, Kevin Meaney wrote:
> I didn't say take them out. I said why do they need to return an autoreleased
> object. Why can't they just return an object like alloc init... does.
Because if they returned an object that wasn't autoreleased (i.e. that the
caller needs to
On 16 Feb 2014, at 17:06, Jens Alfke wrote:
> On Feb 16, 2014, at 5:27 AM, Kevin Meaney wrote:
>
>> Is the only reason for interoperability with manual retain-release code?
>
> For backward compatibility. Nearly every piece of existing Cocoa code uses
> these methods, so there's no way they
On Feb 16, 2014, at 5:27 AM, Kevin Meaney wrote:
> Is the only reason for interoperability with manual retain-release code?
For backward compatibility. Nearly every piece of existing Cocoa code uses
these methods, so there's no way they could take them out.
> It seems that it creates an unnec
I have an NSTableView with several columns bound to an NSArrayController
which manages the array of my custom objects.
Undo of course works while editing a cell in the NSTableView, but once the
edit is complete, I need to manage it myself.
How is the best way to do this?
I need to know the origi
On Feb 16, 2014, at 7:27 AM, Kevin Meaney wrote:
> Why do these methods need to return an autoreleased object, why can't they
> behave the same as:
>
> NSString *myString = [[NSString alloc] initWithFormat:@"%@", @"my String];
>
> Is the only reason for interoperability with manual retain-rele
Hey guys,
I have a serious problem with the CollectionView and I don’t understand its
behavior.
My Project has a Splitview into 2 Views, one is a Scrollview with a
CollectionView the one is a normal NSView with background image.
The other one with the CollectionView has multiple items with own
On 16 Feb, 2014, at 9:27 pm, Kevin Meaney wrote:
> I've realized that my understanding of ARC is not as good as I thought it
> was. So I'll be asking couple of questions.
>
> With ARC I don't understand why autorelease pools are needed anymore except
> for with objects passed by reference. Wh
I've realized that my understanding of ARC is not as good as I thought it was.
So I'll be asking couple of questions.
With ARC I don't understand why autorelease pools are needed anymore except for
with objects passed by reference. What I mean by that is that class methods
like:
NSString *mySt
Yes, my solution is to put all the items in a simple menu without submenus
and indent the subitems, as we can see here
https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcQxp-WYrNvXgqix4JRmVyc4
G-4FXagcs6-PQv8gHr6eLndafMHp
Easy, simple, it works. Thank you for your suggestions. They drove me he
> On 2014/02/16, at 17:50, Rick Mann wrote:
>
> In the WWDC 2013 video about Core Data performance, they used an Earthquake
> app. But this one is nicer than the threaded Core Data sample code. The
> sample you can get uses none of the optimizations shown in the WWDC 2013 talk.
>
> Is that Ea
In the WWDC 2013 video about Core Data performance, they used an Earthquake
app. But this one is nicer than the threaded Core Data sample code. The sample
you can get uses none of the optimizations shown in the WWDC 2013 talk.
Is that Earthquake sample available anywhere?
If not, Apple really s
19 matches
Mail list logo
