Re: Cocoa-dev Digest, Vol 8, Issue 822
Re: Cocoa-dev Digest, Vol 8, Issue 822
- Subject: Re: Cocoa-dev Digest, Vol 8, Issue 822
- From: Daniel Steinberg <email@hidden>
- Date: Thu, 13 Oct 2011 22:46:53 -0400
Mark's interview is up
D
On Oct 13, 2011, at 9:35 PM, email@hidden wrote:
> Send Cocoa-dev mailing list submissions to
> email@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.apple.com/mailman/listinfo/cocoa-dev
> or, via email, send a message with subject or body 'help' to
> email@hidden
>
> You can reach the person managing the list at
> email@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cocoa-dev digest..."
>
>
> Today's Topics:
>
> 1. NSArrayController Update Delay (Richard Somers)
> 2. Re: Select model objects with NSTableView using cocoa
> bindings (Luc Van Bogaert)
> 3. Re: NSArrayController Update Delay (Keary Suska)
> 4. Re: Select model objects with NSTableView using cocoa
> bindings (Quincey Morris)
> 5. Re: NSArrayController Update Delay (Richard Somers)
> 6. Re: NSArrayController Update Delay (Mike Abdullah)
> 7. Re: Reusing XCode 4 Core Data Model. (Ben)
> 8. Pop-up menu in NSCollectionView (Graham Cox)
> 9. Namespace clash problem (Graham Cox)
> 10. Re: Pop-up menu in NSCollectionView (Lee Ann Rucker)
> 11. Re: Best way to parse a time today? (Dave DeLong)
> 12. Re: Namespace clash problem (Jens Alfke)
> 13. Re: Namespace clash problem (Kyle Sluder)
> 14. Re: Namespace clash problem (Graham Cox)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 13 Oct 2011 14:20:40 -0600
> From: Richard Somers <email@hidden>
> Subject: NSArrayController Update Delay
> To: email@hidden
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> Consider a NSArrayController in entity mode. When a managed object is inserted into the managed object context the controller's arrangedObjects property is not updated immediately.
>
> Calling a controller 'fetch:' immediately after inserting the managed object into the managed object context does not help. The controller's arrangedObjects property is still not updated.
>
> Perhaps there is a KVO change notification delay between the time when the managed object is inserted into the managed object context and the time when the controller finds out about the change.
>
> Does anyone have any insight into what is going or how to force the NSArrayController's arrangedObjects property to update?
>
> Thanks so much.
>
> --Richard
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 13 Oct 2011 22:44:03 +0200
> From: Luc Van Bogaert <email@hidden>
> Subject: Re: Select model objects with NSTableView using cocoa
> bindings
> To: Quincey Morris <email@hidden>
> Cc: Cocoa Dev List <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; CHARSET=US-ASCII
>
> On 12 Oct 2011, at 23:22, Quincey Morris wrote:
>
>> On Oct 12, 2011, at 13:31 , Luc Van Bogaert wrote:
>>
>>> I'm wondering if I should create a NSIndexSet property in my model object and bind it to the NSArrayController's 'selectedIndexes' key?
>>
>> Yes, but you've got the terminology wrong. The relevant concept here is a binding name, and it's "selectionIndexes", not "selectedIndexes". NSArrayController also has a "selectionIndexes" property, but that's what the table view binds to, and is not involved here (except as an "intermediary" property between the table view and the data model -- which is why a NSArrayController is a "mediating" controller.) Also, binding actually goes in the other direction -- you bind the object with the binding (the array controller) to the object with the property (the model). But I'm pretty sure that's what you meant. :)
>>
>
> Thanks, I got this working in one 'direction', ie. when the selection in the table is changed, this is reflected in my UI and the 'selected' Dot objects are drawn in a different color. For this, I decided to use a NSMutableIndexSet 'dotSelectionIndexes' property in my model object, bound to the array controller's 'selectionIndexes' binding.
>
> But I'm afraid this still remains a little blurry on how to get the binding work in the other direction. Meaning, I would like to click a Dot object in my UI to select it, and this should change the selection in the table, resulting in turn in the Dot being redrawn with a different color.
>
> I was hoping that by just adding or replacing the contents of my 'dotSelectionIndexes' ivar (hence the choice for a NSMutableIndexSet) with the index of the clicked Dot, would trigger a selection change in the table because of the binding. It seems this doesn't work. So, obviously I'm still missing something.
>
> --
> Luc.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 13 Oct 2011 15:12:22 -0600
> From: Keary Suska <email@hidden>
> Subject: Re: NSArrayController Update Delay
> To: Richard Somers <email@hidden>
> Cc: "Cocoa-Dev \(Apple\)" <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> On Oct 13, 2011, at 2:20 PM, Richard Somers wrote:
>
>> Consider a NSArrayController in entity mode. When a managed object is inserted into the managed object context the controller's arrangedObjects property is not updated immediately.
>
> How is this happening? Via code? or Via the NSArrayController (add: or insert:)? In the latter case the docs say, "Beginning with Mac OS X v10.4 the result of this method is deferred until the next iteration of the runloop so that the error presentation mechanism can provide feedback as a sheet."
>
>> Calling a controller 'fetch:' immediately after inserting the managed object into the managed object context does not help. The controller's arrangedObjects property is still not updated.
>>
>> Perhaps there is a KVO change notification delay between the time when the managed object is inserted into the managed object context and the time when the controller finds out about the change.
>
> Not in my experience (except as noted above).
>
>> Does anyone have any insight into what is going or how to force the NSArrayController's arrangedObjects property to update?
>
> If the action has been deferred as described above, you are mostly out of luck. You could chance manually turning the runloop but it is fragile and generally recommended against.
>
> Best,
>
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 13 Oct 2011 15:21:42 -0700
> From: Quincey Morris <email@hidden>
> Subject: Re: Select model objects with NSTableView using cocoa
> bindings
> To: Luc Van Bogaert <email@hidden>
> Cc: Cocoa Dev List <email@hidden>
> Message-ID:
> <email@hidden>
> Content-Type: text/plain; charset=windows-1252
>
> On Oct 13, 2011, at 13:44 , Luc Van Bogaert wrote:
>
>> Thanks, I got this working in one 'direction', ie. when the selection in the table is changed, this is reflected in my UI and the 'selected' Dot objects are drawn in a different color. For this, I decided to use a NSMutableIndexSet 'dotSelectionIndexes' property in my model object, bound to the array controller's 'selectionIndexes' binding.
>
> ∑ bound *from* ∑ ;)
>
>> But I'm afraid this still remains a little blurry on how to get the binding work in the other direction. Meaning, I would like to click a Dot object in my UI to select it, and this should change the selection in the table, resulting in turn in the Dot being redrawn with a different color.
>>
>> I was hoping that by just adding or replacing the contents of my 'dotSelectionIndexes' ivar (hence the choice for a NSMutableIndexSet) with the index of the clicked Dot, would trigger a selection change in the table because of the binding. It seems this doesn't work. So, obviously I'm still missing something.
>
> So close! A simple NSMutableIndexSet property isn't KVO compliant, but the array controller bound *to* it is watching with KVO, so the thing fizzles.
>
> Use a NSIndexSet property instead of a NSMutableIndexSet, and change the property by assigning it a new (immutable) index set -- that is, via the setter.
>
> This means that you'll create many NSIndexSet objects at times, but unless you have vast numbers of Dot objects this is not likely to make a measurable impact on performance. If it did, it's not that hard to use a NSIndexSet property backed by a NSMutableIndexSet ivar, along with some non-standard non-KVC accessors your Dot objects would use to update the property, but you'd have to generate the requisite KVO notifications manually, and write a custom setter.
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 13 Oct 2011 16:44:41 -0600
> From: Richard Somers <email@hidden>
> Subject: Re: NSArrayController Update Delay
> To: Keary Suska <email@hidden>
> Cc: email@hidden
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> On Oct 13, 2011, at 3:12 PM, Keary Suska wrote:
>
>> How is this happening? Via code? or Via the NSArrayController (add: or insert:)? In the latter case the docs say, "Beginning with Mac OS X v10.4 the result of this method is deferred until the next iteration of the runloop so that the error presentation mechanism can provide feedback as a sheet."
>
> I have been inserting objects into the managed object context in code like this.
>
> [[NSManagedObject alloc] initWithEntity:entity insertIntoManagedObjectContext:moc];
>
> Sometime later the array controller's arrangedObjects property will be automatically updated.
>
> I have not been using NSArrayController's add: or insert: methods because at one time I was using them, in addition to initWithEntity:insertIntoManagedObjectContext:, and I was getting duplicate objects. Although I tried using both of them together just now (first initWithEntity:insertIntoManagedObjectContext: and then add:) and I am not getting any duplicates. So I am a little confused.
>
> Is it normal practice to create a managed object with the designated initializer initWithEntity:insertIntoManagedObjectContext: and also insert the object into the controller using the controller's add: or insert: method?
>
> --Richard
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 13 Oct 2011 23:55:30 +0100
> From: Mike Abdullah <email@hidden>
> Subject: Re: NSArrayController Update Delay
> To: Richard Somers <email@hidden>
> Cc: email@hidden
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
>
> On 13 Oct 2011, at 21:20, Richard Somers wrote:
>
>> Consider a NSArrayController in entity mode. When a managed object is inserted into the managed object context the controller's arrangedObjects property is not updated immediately.
>>
>> Calling a controller 'fetch:' immediately after inserting the managed object into the managed object context does not help. The controller's arrangedObjects property is still not updated.
>>
>> Perhaps there is a KVO change notification delay between the time when the managed object is inserted into the managed object context and the time when the controller finds out about the change.
>>
>> Does anyone have any insight into what is going or how to force the NSArrayController's arrangedObjects property to update?
>
> I'm pretty sure the array controller is observing NSManagedObjectContextObjectsDidChangeNotification to arrange its objects. Normally, this doesn't fire until the end of the runloop. But you can force it to by calling -[NSManagedObjectContext processPendingChanges]
>
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 14 Oct 2011 00:13:07 +0100
> From: Ben <email@hidden>
> Subject: Re: Reusing XCode 4 Core Data Model.
> To: "email@hidden List" <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=windows-1252
>
> Thanks for the reply. I previously attempted to copy the way you suggest, but sadly it also does not work.
>
>
> On 13 Oct 2011, at 18:17, Martin Hewitson wrote:
>
>> I think selecting the entities in the other non-graphical editor works for copy and paste.
>>
>> Martin
>>
>> On Oct 13, 2011, at 01:12 PM, Ben wrote:
>>
>>> In Xcode 3, if I needed to reuse parts of the Core Data Model from a previous project, I would simply highlight the entities required in the Graph Editor, copy then paste them into the Graph Editor of my new project∑ simple.
>>>
>>> XCode 4 however∑ when I try to copy and past the entities, nothing. How do I achieve the same thing in XCode 4? _______________________________________________
>>>
>>> Cocoa-dev mailing list (email@hidden)
>>>
>>> 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:
>>>
>>> This email sent to email@hidden
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Martin Hewitson
>> Albert-Einstein-Institut
>> Max-Planck-Institut fuer
>> Gravitationsphysik und Universitaet Hannover
>> Callinstr. 38, 30167 Hannover, Germany
>> Tel: +49-511-762-17121, Fax: +49-511-762-5861
>> E-Mail: email@hidden
>> WWW: http://www.aei.mpg.de/~hewitson
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>>
>>
>>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 14 Oct 2011 10:13:06 +1100
> From: Graham Cox <email@hidden>
> Subject: Pop-up menu in NSCollectionView
> To: Cocoa Dev <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> I'm using NSCollectionView to display a bunch of items. I have the 'menu' outlet of this view connected to a menu which in turn sends an action to File's Owner.
>
> On 10.7 this works as expected (menu is displayed when right-clicking in the view), but on 10.6.x, the menu is not displayed.
>
> Does anyone know why this is and whether it's possible to work around it?
>
> --Graham
>
>
>
>
> ------------------------------
>
> Message: 9
> Date: Fri, 14 Oct 2011 10:29:25 +1100
> From: Graham Cox <email@hidden>
> Subject: Namespace clash problem
> To: Cocoa Dev <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> I just updated to Xcode 4.2 from 4.1, and I'm getting a new warning when I compile: "Multiple methods named 'style' found"
>
> When I go into this warning, it further states it's using [NSProgressIndicator style] instead of my own declared method style which exists in many different objects (and which would be correct).
>
> (<RANT> why do Apple have to steal such obvious names when they know there is a namespace problem? This could easily have been named 'progressIndicatorStyle' and have much less chance of clashing with user code. I may have been a bit too generic using 'style' myself, but on the other hand I have something actually called a style which is an object and so using the property 'style' is actually appropriate! </RANT>)
>
> The question is, while this doesn't seem to cause any problems, I'm a little concerned because a) I didn't get this warning in previous versions of Xcode, b) the return types are different (NSUInteger versus an id) and c) I don't like having warnings. Changing my code to eliminate this name is going to be very, very difficult - it's used in hundreds of different places. Typecasting the return type to be the explicit object type I expect does not eliminate the warning. (I'm thinking it's safe because the return type of NSUInteger and id uses the same version of objc_message_send, but that's just lucky. If Apple's property returned a float I"d be in serious trouble.)
>
> Is there a way to force the compiler to use the correct one?
>
> --Graham
>
> ------------------------------
>
> Message: 10
> Date: Thu, 13 Oct 2011 16:39:36 -0700
> From: Lee Ann Rucker <email@hidden>
> Subject: Re: Pop-up menu in NSCollectionView
> To: Graham Cox <email@hidden>
> Cc: Cocoa Dev <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> Mine works fine on 10.6 and 10.7, but I'm implementing menuForEvent: in my NSCollectionView subclass instead of using bindings
>
> On Oct 13, 2011, at 4:13 PM, Graham Cox wrote:
>
>> I'm using NSCollectionView to display a bunch of items. I have the 'menu' outlet of this view connected to a menu which in turn sends an action to File's Owner.
>>
>> On 10.7 this works as expected (menu is displayed when right-clicking in the view), but on 10.6.x, the menu is not displayed.
>>
>> Does anyone know why this is and whether it's possible to work around it?
>>
>> --Graham
>>
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
>
>
> ------------------------------
>
> Message: 11
> Date: Thu, 13 Oct 2011 17:03:14 -0700
> From: Dave DeLong <email@hidden>
> Subject: Re: Best way to parse a time today?
> To: "email@hidden List" <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; CHARSET=US-ASCII
>
> Yep, this is what I was referring to. I'm not sure there's anything you can do about this, since it's technically the input that is incorrect. However, it's still good to be aware that these edge cases exist.
>
> Dave
>
> On Oct 13, 2011, at 10:39 AM, Rick Mann wrote:
>
>> I think the concern is this. Say today is the day that a time change occurs. In the US, this happens at 2 am. When you move the clocks forward, the instant the clock would roll from 1:59:59.999 to 2:00:00.000, it actually rolls to 3:00:00.000. All of the times in the half-open interval (2:00, 3:00] are "invalid."
>>
>> So, if on that day, I try to parse the string "02:17", what's the right result? My guess would be "03:17", but I'd have to test that case to be sure it does that.
>>
>> --
>> Rick
>
>
> ------------------------------
>
> Message: 12
> Date: Thu, 13 Oct 2011 17:28:16 -0700
> From: Jens Alfke <email@hidden>
> Subject: Re: Namespace clash problem
> To: Graham Cox <email@hidden>
> Cc: Cocoa Dev <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=windows-1252
>
>
> On Oct 13, 2011, at 4:29 PM, Graham Cox wrote:
>
>> When I go into this warning, it further states it's using [NSProgressIndicator style] instead of my own declared method style which exists in many different objects (and which would be correct).
>
> This only happens when calling -style on an untyped (id) pointer. Cast the pointer to your class and you won‚t have a problem. Instead of
> [[array lastObject] style]
> use
> [(MyClass*)[array lastObject] style]
> This has the added advantage that, if you ever renamed or removed your -style method, the compiler would be able to warn you if you didn‚t fix this call.
>
>> (<RANT> why do Apple have to steal such obvious names when they know there is a namespace problem? This could easily have been named 'progressIndicatorStyle' and have much less chance of clashing with user code.
>
> I would rather have shorter, clearer names in framework classes. The name-collision thing doesn‚t happen to me often, and when it does I just use a typecast like above.
>
> ˜Jens
>
> ------------------------------
>
> Message: 13
> Date: Thu, 13 Oct 2011 17:34:16 -0700
> From: Kyle Sluder <email@hidden>
> Subject: Re: Namespace clash problem
> To: Graham Cox <email@hidden>
> Cc: Cocoa Dev <email@hidden>
> Message-ID:
> <email@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Thu, Oct 13, 2011 at 4:29 PM, Graham Cox <email@hidden> wrote:
>> Typecasting the return type to be the explicit object type I expect does not eliminate the warning.
>
> You need to typecast the recipient, not the return type.
>
> --Kyle Sluder
>
>
> ------------------------------
>
> Message: 14
> Date: Fri, 14 Oct 2011 12:32:16 +1100
> From: Graham Cox <email@hidden>
> Subject: Re: Namespace clash problem
> To: Jens Alfke <email@hidden>
> Cc: Cocoa Dev <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=windows-1252
>
> Ah, that's clear, but I now see why I'm going wrong.
>
> The object in question is actually a class, where it has a class method +style. But the class is passed as the 'object' parameter of a notification, which has type id. How do I typecast that to the precise class type I'm expecting? Using (MyClass*) doesn't work because that is an instance. It's probably obvious, but I'm not stumbling upon it...
>
> --Graham
>
>
> On 14/10/2011, at 11:28 AM, Jens Alfke wrote:
>
>>
>> On Oct 13, 2011, at 4:29 PM, Graham Cox wrote:
>>
>>> When I go into this warning, it further states it's using [NSProgressIndicator style] instead of my own declared method style which exists in many different objects (and which would be correct).
>>
>> This only happens when calling -style on an untyped (id) pointer. Cast the pointer to your class and you won‚t have a problem. Instead of
>> [[array lastObject] style]
>> use
>> [(MyClass*)[array lastObject] style]
>> This has the added advantage that, if you ever renamed or removed your -style method, the compiler would be able to warn you if you didn‚t fix this call.
>>
>>> (<RANT> why do Apple have to steal such obvious names when they know there is a namespace problem? This could easily have been named 'progressIndicatorStyle' and have much less chance of clashing with user code.
>>
>> I would rather have shorter, clearer names in framework classes. The name-collision thing doesn‚t happen to me often, and when it does I just use a typecast like above.
>>
>> ˜Jens
>
>
>
> ------------------------------
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins (at) lists.apple.com
>
> http://lists.apple.com/mailman/listinfo/cocoa-dev
>
>
> End of Cocoa-dev Digest, Vol 8, Issue 822
> *****************************************
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden