Mark's interview is up D On Oct 13, 2011, at 9:35 PM, cocoa-dev-requ...@lists.apple.com wrote:
> Send Cocoa-dev mailing list submissions to > cocoa-dev@lists.apple.com > > 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 > cocoa-dev-requ...@lists.apple.com > > You can reach the person managing the list at > cocoa-dev-ow...@lists.apple.com > > 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 <rsomers.li...@infowest.com> > Subject: NSArrayController Update Delay > To: cocoa-dev@lists.apple.com > Message-ID: <2590f57e-4900-4552-beff-d081660bb...@infowest.com> > 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 <luc.van.boga...@me.com> > Subject: Re: Select model objects with NSTableView using cocoa > bindings > To: Quincey Morris <quinceymor...@rivergatesoftware.com> > Cc: Cocoa Dev List <cocoa-dev@lists.apple.com> > Message-ID: <3af59652-ac10-4fe7-a050-692fe8012...@me.com> > 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 <cocoa-...@esoteritech.com> > Subject: Re: NSArrayController Update Delay > To: Richard Somers <rsomers.li...@infowest.com> > Cc: "Cocoa-Dev \(Apple\)" <cocoa-dev@lists.apple.com> > Message-ID: <ba4a4474-afd6-4818-9e7e-4b3842e88...@esoteritech.com> > 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 <quinceymor...@rivergatesoftware.com> > Subject: Re: Select model objects with NSTableView using cocoa > bindings > To: Luc Van Bogaert <luc.van.boga...@me.com> > Cc: Cocoa Dev List <cocoa-dev@lists.apple.com> > Message-ID: > <afa41da9-9cc0-4af4-b262-b7e922bdc...@rivergatesoftware.com> > 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 <rsomers.li...@infowest.com> > Subject: Re: NSArrayController Update Delay > To: Keary Suska <cocoa-...@esoteritech.com> > Cc: cocoa-dev@lists.apple.com > Message-ID: <ba3e60aa-5842-42ef-b984-99ff90fbc...@infowest.com> > 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 <cocoa...@mikeabdullah.net> > Subject: Re: NSArrayController Update Delay > To: Richard Somers <rsomers.li...@infowest.com> > Cc: cocoa-dev@lists.apple.com > Message-ID: <3439cbcf-c072-4f98-b1f6-15218f4b4...@mikeabdullah.net> > 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 <southwestmons...@googlemail.com> > Subject: Re: Reusing XCode 4 Core Data Model. > To: "cocoa-dev@lists.apple.com List" <cocoa-dev@lists.apple.com> > Message-ID: <8ec957b9-9619-4ab4-b856-01b4c13cf...@googlemail.com> > 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 (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: >>> http://lists.apple.com/mailman/options/cocoa-dev/martin.hewitson%40aei.mpg.de >>> >>> This email sent to martin.hewit...@aei.mpg.de >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 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: martin.hewit...@aei.mpg.de >> WWW: http://www.aei.mpg.de/~hewitson >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> >> >> >> > > > > ------------------------------ > > Message: 8 > Date: Fri, 14 Oct 2011 10:13:06 +1100 > From: Graham Cox <graham....@bigpond.com> > Subject: Pop-up menu in NSCollectionView > To: Cocoa Dev <cocoa-dev@lists.apple.com> > Message-ID: <01b83e68-c2d7-4fb5-b956-608c58423...@bigpond.com> > 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 <graham....@bigpond.com> > Subject: Namespace clash problem > To: Cocoa Dev <cocoa-dev@lists.apple.com> > Message-ID: <4b82883e-3ea8-45e9-9452-090ce9925...@bigpond.com> > 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 <lruc...@vmware.com> > Subject: Re: Pop-up menu in NSCollectionView > To: Graham Cox <graham....@bigpond.com> > Cc: Cocoa Dev <cocoa-dev@lists.apple.com> > Message-ID: <ac2cda7c-652a-4554-b4b7-691b7b088...@vmware.com> > 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 (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: >> http://lists.apple.com/mailman/options/cocoa-dev/lrucker%40vmware.com >> >> This email sent to lruc...@vmware.com > > > > ------------------------------ > > Message: 11 > Date: Thu, 13 Oct 2011 17:03:14 -0700 > From: Dave DeLong <davedel...@me.com> > Subject: Re: Best way to parse a time today? > To: "cocoa-dev@lists.apple.com List" <cocoa-dev@lists.apple.com> > Message-ID: <8db16424-c7fc-4b14-b9c6-0e8d71485...@me.com> > 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 <j...@mooseyard.com> > Subject: Re: Namespace clash problem > To: Graham Cox <graham....@bigpond.com> > Cc: Cocoa Dev <cocoa-dev@lists.apple.com> > Message-ID: <039fe083-fb2a-4c66-b3e0-886fe0161...@mooseyard.com> > 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 <kyle.slu...@gmail.com> > Subject: Re: Namespace clash problem > To: Graham Cox <graham....@bigpond.com> > Cc: Cocoa Dev <cocoa-dev@lists.apple.com> > Message-ID: > <canes-cwz8so1pxfavv7c7zwx4qkjrx_ypikgauokowxrjrp...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Thu, Oct 13, 2011 at 4:29 PM, Graham Cox <graham....@bigpond.com> 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 <graham....@bigpond.com> > Subject: Re: Namespace clash problem > To: Jens Alfke <j...@mooseyard.com> > Cc: Cocoa Dev <cocoa-dev@lists.apple.com> > Message-ID: <42c0d195-ab84-43bb-91f5-56521d36f...@bigpond.com> > 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 (Cocoa-dev@lists.apple.com) > > 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 (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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
