Re: NSTableView doesn't show data until I click on a header
On Apr 29, 2012, at 9:22 AM, Koen van der Drift koenvanderdr...@gmail.com
wrote:
So for future reference, my data model is an NSMutableArray. Instead of
adding objects by calling addObject, I need to call it as follows:
- (void)addMyObject:(MyObject *)obj
{
NSMutableArray *temp = [self mutableArrayValueForKey: @myArray];
[temp addObject: obj];
}
Is there any reason not to implement the appropriate KVC accessor methods for
myArray?
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/AccessorConventions.html#//apple_ref/doc/uid/20002174-BAJEAIEE
(See also
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueObserving/Articles/KVOCompliance.html#//apple_ref/doc/uid/20002178-BAJEAIEE.)
mmalc
___
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: Core data - binding related problem in NSNumberFormatter and NSDatePicker
On Dec 17, 2010, at 1:24 pm, Flavio Donadio wrote: Lesson learnt, but I took that code directly from Apple. Check Movie 11 on this page: http://developer.apple.com/cocoa/coredatatutorial/index.html That's an overview tutorial from several years ago, prior to the introduction of dynamically-generated accessor methods, and intended to illustrate a quick first-pass. The current documentation is quite explicit: You can also use key-value coding (KVC) to get or set the value of a simple attribute as illustrated in the following code fragment. Using KVC, though, is considerably less efficient than using accessor methods, so you should only use KVC when necessary (for example when you are choosing the key or key path dynamically). http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdUsingMOs.html%23//apple_ref/doc/uid/TP40001803-CJBDBHCB mmalc ___ 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
Re: Core data - binding related problem in NSNumberFormatter and NSDatePicker
On Dec 16, 2010, at 3:45 pm, Flavio Donadio wrote: [self setValue:[NSDate date] forKey:@datePurchased]; Don't use KVC to set managed object properties unless you have a good reason (dynamic code). Core Data generates accessor methods for you that are much more efficient to use: [self setDatePurchased:[NSDate date]]; mmalc ___ 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
Re: Programmatic initialization of a NSManagedObject with a Relationship
On Oct 30, 2010, at 4:46 pm, Paul Johnson wrote: I have 2 tableviews (A and B) in a window. Both use Core Data. A 3rd tableview (in a drawer) has a complete list of items that I can selectively Drag and Drop to tableview B. I have almost implemented the Drag and Drop, but one step is missing. Tableview B has a Relationship to an item in tableview A, and I need to set up that pointer in my tableview B array controller (in tableView:acceptDrop:row:dropOperation:). I haven’t figured out how to do that yet. Any suggestions? The basic question -- how do you establish a relationship between two managed objects -- is answered in the documentation: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdRelationships.html%23//apple_ref/doc/uid/TP40001857-CJBDBHCB How you find out the item in Tableview A should be obvious from http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/DragandDrop/UsingDragAndDrop.html%23//apple_ref/doc/uid/2726-BABFIDAB. The Core Data Programming Guide article, however, also notes: Core Data does not let you create relationships that cross stores. If you need to create a relationship from objects in one store to objects in another, you should consider using fetched properties. Given your earlier statement: On Oct 27, 2010, at 8:38 pm, Paul Johnson wrote: *The source table and destination table are each supplied data using separate managed object contexts. (The model for the destination table just has an additional relationship defined, but the attributes are the same otherwise.) If you're using different models for the two table views, presumably you're using two stores...? mmalc ___ 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
Re: Designated Initializer
On Oct 30, 2010, at 12:12 pm, Dave Carrigan wrote: All initialized objects have at some point called super; they aren't fully initialized otherwise. In the implementation, the non-designated initializers typically chain to the designated initializer, which in turn chains to super's (usually designated) initializer. So just because a designated initializer didn't call super's designated initializer, it doesn't mean that super's designated initialer was not invoked; it was. This is not the case. You should always invoke super's designated initialiser (or another [initializer] that ultimately invokes the designated initializer): http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocAllocInit.html%23//apple_ref/doc/uid/TP30001163-CH22-SW1 mmalc ___ 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
Re: Drag and drop between two table views.
On Oct 27, 2010, at 8:38 pm, Paul Johnson wrote: I took your suggestion to archive the array to a NSData object. I needed to implement encodeWithCoder for the object that defines the data for a row (containing 3 columns with an NSString in each column). I used the Data Modeler to define the row objects and then created the initial declaration and implementation files. Now I needed to added encodeWithCoder and initWithCoder methods. Now I'm getting the message *Failed to call designated initializer on NSManagedObject class 'Market'* *when I try to unarchive. I'm really unclear on how to work with Core Data in this situation.* Are you trying to use archiving with Core Data? You shouldn't. When you create a managed object, precisely as the error message states, you need to use its designated initialiser. What you do to support drag and drop depends on the functionality you want. If you want to copy the objects, then you need to create representations that are not managed objects -- for example a dictionary -- as shown in http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/NSPersistentDocumentTutorial/05_CopyAndPaste/copyAndPaste.html%23//apple_ref/doc/uid/TP40002833-SW1. If you want to move the objects or otherwise simply create different references to the originals, then you pass the managed object IDs. mmalc ___ 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
Re: Drag and drop between two table views.
On Oct 28, 2010, at 2:20 pm, Paul Johnson wrote: The model for the data in the destination tableview is essentially the same as for the source tableview. The only difference is that the data model for the destination tableview has an additional entity and a relationship. Then it's not the same model. Per my previous reply, the approach you should take is illustrated in the NSPersistentDocument tutorial; general strategies are also discussed in the Core Data Programming Guide: http://pubsbuild.apple.com/Messier/Releases/BaroloDevLib/recipes/xcode_help-core_data_modeling_tool/index.html Right now I'm getting an error message when I try to decode the pasteboard data: Failed to call designated initializer on NSManagedObject class 'Market' I guess I can write more code and just copy the strings to build an array that doesn't depend on NSManagedObject, but perhaps someone can help me avoid doing this, but instead recommend a method makes drag and drop compatible with Core Data. See previous reply. mmalc ___ 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
Re: Drag and drop between 2 table views
Paul Johnson wrote: I could build an array with the strings I want to drag and drop and that appears to be the proper way to implement this. So far I've found that info on Core Data is rather sparse, especially as it pertains to sample code. The Core Data Programming Guide contains a section that specifically addresses Copy and Paste and Drag and Drop... I believe I've found the answer to my drag and drop problem: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdUsingMOs.html Drag and Drop is just a glorified copy/paste and on that web page I found: If you just want to copy a managed object’s attributes, then in many cases the best strategy may be in the copy operation to create a dictionary (property list) representation of a managed object, then in the paste operation to create a new managed object and populate it using the dictionary. Per previous reply: On Oct 28, 2010, at 9:25 am, mmalc Crawford wrote: What you do to support drag and drop depends on the functionality you want. If you want to copy the objects, then you need to create representations that are not managed objects -- for example a dictionary -- as shown in http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/NSPersistentDocumentTutorial/05_CopyAndPaste/copyAndPaste.html%23//apple_ref/doc/uid/TP40002833-SW1. mmalc ___ 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
Re: Access object from another view
On Sep 21, 2010, at 2:49 pm, Steve Wetzel wrote: Then [self.view addSubView:viewController2.view]; brings up the subview. You should [almost certainly] not be doing this. If you want to display another view controller's view, you should use an appropriate technique to present the view controller itself. In many case this would involve using a navigation controller (UINavigationController). To learn more about application architecture using view controllers, read the View Controller Programming Guide http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/Introduction/Introduction.html%23//apple_ref/doc/uid/TP40007457 For general design guidelines etc. see http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/CoreApplication/CoreApplication.html%23//apple_ref/doc/uid/TP40007072-CH3-SW14 To address the general question of how do I access an object from another view: As you appear to be asking it, you don't. The general pattern is that before you present a view, you pass to its view controller any data that will be needed for display. It's up to the view controller to then project the relevant information into its view. mmalc ___ 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
Re: Simple instance [[alloc] init] question.
On Aug 30, 2010, at 6:37 PM, Dave Geering wrote: // 1) self.serialIDs = [[IRMSerialDetailsDO alloc] init]; The alloc method allocates an instance with a retain count of 1, and assigning it to the serialIDs property bumps it up to 2. In your dealloc method, you will [hopefully] send it a release message which puts it back at 1, but this means the object still survives (i.e. it is not deallocated). // 2) IRMSerialDetailsDO *mySerialIDDO = [[IRMSerialDetailsDO alloc] init]; self.serialIDDO = mySerialIDDO; [mySerialIDDO release]; Here, the alloc creates the instance with a retain count 1, assigning it to the property bumps it up to 2, and the release right afterwards puts it back down to 1. In your dealloc method, you will sent it another release message which puts it at 0, and therefore the instance is deallocated. This is at best misleading, and illustrates why people are typically discouraged from reformulating the memory management rules. First, from the original post: header file.h @property(nonatomic, release) IRMSerialDetailsDO *serialIDs; ... body.m @synthesize mySerialIDDO This is just wrong. There is no 'release' keyword for a property declaration, and the name of the property in the declaration does not match that in the synthesize statement. Assuming that the intent was: header file.h @property(nonatomic, retain) IRMSerialDetailsDO * mySerialIDDO; ... body.m @synthesize mySerialIDDO then if you set the mySerialIDDO variable using the corresponding accessor method, you end up owning the object. It is your responsibility to subsequently relinquish ownership in dealloc. Whether or not this results in the object being deallocated depends on what other objects may have claimed ownership in the interim, and is of no interest to you. As others have noted, adhering to the memory management rules (http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html), by convention this results in a memory leak: self.serialIDs = [[IRMSerialDetailsDO alloc] init]; To address the issue of the second pattern: IRMSerialDetailsDO *mySerialIDDO = [[IRMSerialDetailsDO alloc] init]; self.serialIDDO = mySerialIDDO; [mySerialIDDO release]; This is explained in the Your First iOS Application tutorial: http://developer.apple.com/iphone/library/documentation/iPhone/Conceptual/iPhone101/Articles/03_AddingViewController.html#//apple_ref/doc/uid/TP40007514-CH5-SW1 It is, and remains, best practice to avoid using autorelease where possible. Autoreleasing objects means they may end up living longer than is strictly necessary, and this adds to your application's memory footprint. Not something you want on a deive with a constrained amount of memory. mmalc ___ 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
Re: Array controllers in code?
On Jul 22, 2010, at 2:05 am, Amy Gibbs wrote: Some things I want to do though need to be actually coded, but how do I reference the Arrays/Array controllers in the code? Do I need to declare them? They aren't at the moment that I can see, but somehow it's using them. All the tutorials I find either cover everything in code (kind of Pre-Core Data) or do everything with bindings. An example of accessing an array controller in code is give here: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/NSPersistentDocumentTutorial/05_CopyAndPaste/copyAndPaste.html mmalc ___ 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
Re: managing split view iPad
On Jul 19, 2010, at 12:19 am, Andrea Mattiuz wrote: I can't manage the change of a navigation controller on the right side of a split view application (iPad) after a tap on the left side. The behavior of this app would be similar to the 'settings' app in the iPad simulator. any suggestions or examples would be very appreciated. One approach is illustrated in the MultipleDetailViews example: http://developer.apple.com/iphone/library/samplecode/MultipleDetailViews/Introduction/Intro.html mmalc ___ 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
Re: Managing Files with CoreData
On Jul 18, 2010, at 1:20 pm, Gordon Apple wrote: I have a series of questions about using CoreData (iPad). Although CoreData is supposedly easy to use, I have found it anything but. Per Keary's reply, the documentation makes it abundantly clear that it's not a beginner's tool. It comes with a number of prerequisites... It is extremely finicky and unforgiving. ... you have to use it correctly, yes... In fact, even with DTS support, I have never been able to get NSFetchedResultsController to work using a cache. The standard Xcode Navigation-based application project template shows you how you can use a fetched results controller with a cache. What are you doing that doesn't match up with that? You haven't said in what way it's not working? My main entity has three references (one-to-one and one-to-many) to identical entities defined as class File (a managed object). File is not defined in the graphical model and is the only class (for the referenced entities) defined in the code. You mean that there is no File entity in the managed object model? Well, that would be a problem; if this is the case, it's not clear how you would expect this to work? Question 1: The FRC is for the main entity and sorts on the main entity's own name attribute. Is there anything is what I described above which could be interfering with using an FRC cache? What is the name of the entity, and what problem are you observing with the cache? You haven't said anything about how you're using the controller? Are you changing the predicate every time you use it, for example? Question 2: In the File class, what should I override to delete the actual associated file when a file object is deleted from the database? (I'm currently doing that separately when deleting the managed object.) Does NSManagedObject's dealloc get called? The documentation for dealloc is quite explicit: You should typically not override this method—instead you should put “clean-up” code in prepareForDeletion or didTurnIntoFault. http://developer.apple.com/mac/library/documentation/Cocoa/Reference/CoreDataFramework/Classes/NSManagedObject_Class/Reference/NSManagedObject.html#//apple_ref/occ/instm/NSManagedObject/dealloc Question 3: The main entity has several NSNumbers. Should I write translators for each of these to make life easier? (Why wasn't this built into CoreData in the first place?) The documentation addresses this issue directly: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdAccessorMethods.html#//apple_ref/doc/uid/TP40002154-SW1 and it's part of the introductory tutorial: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreDataUtilityTutorial/Articles/06_runClass.html#//apple_ref/doc/uid/TP40001800-CH234-TP9 Question 4: Is there any reason why you can't add additional methods (not ivars) to Managed object code-files? Why would you think you cannot? Again, this is part of the introductory tutorial. http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreDataUtilityTutorial/Articles/06_runClass.html#//apple_ref/doc/uid/TP40001800-CH234-TP9 and from http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdManagedObjects.html#//apple_ref/doc/uid/TP40003397-SW1: You might implement a custom class, for example, to provide custom accessor or validation methods, to use non-standard attributes, to specify dependent keys, to calculate derived values, or to implement any other custom logic. Question 5: I'm currently formulating file URLs in a separate FileManager object. Is there a better way for CoreData to manage file references? Full URLs could be problematic, if later systems change anything. Maybe partial URLs/paths relative to the application's documents folder? Fundamentally, this isn't a Core Data issue... Comment: I have yet to see any sample code or writeups on using CoreData to manage files, which seems like something that should be in common usage. ... Core Data is an object graph management and persistence framework. Outside of the scope of object graph management and persistence, you treat managed objects pretty much just as you would any other. There isn't anything or there is very little in the Core Data documentation about interaction with sound generation, drawing, game playing logic, and so on: although you could use Core Data in a sound manipulation application, a drawing application, or in a game (amongst a myriad of other domains), the patterns and techniques you use are specific to those domains and in general not affected by the fact that you're using Core Data. If you manage file paths, the way you do so is just the same as you would were you not using Core Data. Modulo the fact that Core Data provides a useful method that's called when an object is about to be deleted, which means you can perhaps more readily tie the lifetime of the
Re: Using NSFetchRequest to fetch NSManagedObject subclasses
On Jul 10, 2010, at 7:31 am, Matt James wrote: That's absolutely right, though I'm glad Joanna chimed in since I didn't know that was the common way to generate those classes to begin with (as I said, I'm completely new to the workings of Core Data). This technique is described in the introductory Core Data Tutorial: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreDataUtilityTutorial/Articles/06_runClass.html#//apple_ref/doc/uid/TP40001800-CH234-TP9 or for iOS: http://developer.apple.com/iphone/library/documentation/DataManagement/Conceptual/iPhoneCoreData01/Articles/03_ManagedObject.html#//apple_ref/doc/uid/TP40008305-CH102-SW1 mmalc ___ 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
Re: Regarding MVC design pattern
On May 19, 2010, at 4:38 am, Sherm Pendley wrote:
If you set the ivars directly, as above, the synthesized setters will
NOT be called. For that to happen, you need to use dot-syntax, like
this:
- (void) dealloc {
self.beginButton = nil;
self.endButton = nil;
// etc...
[super dealloc];
}
You do not *need* to use the dot syntax to invoke the accessors synthesised for
a property. You can also use the corresponding accessor method using [] syntax,
e.g.
[self setBeginButton:nil];
However, you should typically not invoke accessor methods in init or dealloc
methods.
mmalc
___
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
Re: Regarding MVC design pattern
On May 19, 2010, at 1:48 am, Sai wrote: 1. Look at the awakeFromNib method of Controller, my output of the retain count to the console are myModel retain count: 5 controller retain count: 17 both number are very surprised me, why is that? I suppose they should be 2 or 1? Can anyone explain please? The documentation is abundantly clear on this issue: http://developer.apple.com/mac/library/documentation/Cocoa/Reference/Foundation/Protocols/NSObject_Protocol/Reference/NSObject.html#//apple_ref/occ/intfm/NSObject/retainCount mmalc ___ 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
Re: Regarding MVC design pattern
On May 20, 2010, at 7:40 am, Thomas Davie wrote: However, you should typically not invoke accessor methods in init or dealloc methods. Can I ask why you shouldn't use them in init? It makes a lot of sense to not use them in alloc/dealloc, but I'm not using them in init... after all, what if I replace the ivar with a derived property from another object? Why should I have to recode my init? http://www.mail-archive.com/cocoa-dev@lists.apple.com/msg39483.html mmalc ___ 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
Re: Solving memory leaks
On Mar 28, 2010, at 10:27 am, Michael Davey wrote: That would be gut for the fact that my fields are released and set to nil whenever a new SELECT query is executed - however, I think I can do this by emptying the array when a new query is done and just counting the size of the array in my fetch method - thanks... Why not follow what someone else suggested earlier in the thread, and the pattern that is recommended in the documentation, and use accessor methods. As soon as you start sprinkling retains and releases throughout your code, you're liable to make a mistake. http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html#//apple_ref/doc/uid/TP40004447 On Mar 28, 2010, at 10:37 am, Michael Davey wrote: However, can anyone answer how I best go about either of the tasks that I have outlined as red, as they are leaking a lot of memory in comparison? You best go about this by reading and understanding the memory management rules. There is no substitute for this. There really isn't much to them: http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html#//apple_ref/doc/uid/2994 mmalc ___ 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
Re: Solving memory leaks
On Mar 28, 2010, at 11:03 am, Philip Mobley wrote: When calling setFields, you are then responsible for releasing the newFields NSMutableArray you created in your sample code, because [newFields mutableCopy] increments the ref counter. This is not correct. [newFields mutableCopy] returns a new object that you own, it does not increment the ref count. You must relinquish ownership of the previous value because you're about to take possession of a new value. mmalc ___ 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
Re: Core data backed UITableView
On Mar 15, 2010, at 5:33 pm, Damien Cooke wrote: [self.myTableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationFade]; Why are you doing this rather than (in addition to? which if so would probably be the cause of the problem) simply implementing the fetched results controller delegate methods as shown in the documentation (http://developer.apple.com/iphone/library/documentation/CoreData/Reference/NSFetchedResultsControllerDelegate_Protocol/Reference/Reference.html) and in the Navigation-based Application template? mmalc ___ 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
Re: Checking integrity of a Core Data document with SQLite store
On Mar 14, 2010, at 7:21 pm, Dave Fernandes wrote: So my question is - how do you detect this before loading the file? I'm aware of the sqlite3 PRAGMA integrity_check, but there does not seem to be a C API for this. Any pointers? http://developer.apple.com/mac/library/documentation/Cocoa/Reference/CoreDataFramework/Classes/NSPersistentStoreCoordinator_Class/NSPersistentStoreCoordinator.html#//apple_ref/doc/c_ref/NSSQLitePragmasOption See http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdPersistentStores.html#//apple_ref/doc/uid/TP40002875 for an example. mmalc ___ 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
Re: Getting relative day-of-week name?
On Feb 24, 2010, at 12:04 pm, Rick Mann wrote: I'd like to take an NSDate and get a relative day-of-week name. For example, if today is 2/24, and the NSDate is some time on 2/23, it would be Yesterday. If the NSDate were 2/22, it would be Monday. Is there an existing format specifier for this (fully localized, etc)? Or must I roll my own for this? NSDateFormatter setDoesRelativeDateFormatting: Specifies whether the receiver uses phrases such as “today” and “tomorrow” for the date component. http://developer.apple.com/mac/library/documentation/Cocoa/Reference/Foundation/Classes/NSDateFormatter_Class/Reference/Reference.html#//apple_ref/occ/instm/NSDateFormatter/setDoesRelativeDateFormatting: mmalc ___ 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
Re: Core Data: Custom to-many relationship setter not being invoked
On Feb 22, 2010, at 2:59 pm, Ken Tabb wrote: Distilling my problem down into the Department Employees example, both are custom NSManagedObject subclasses, each with an inverse to-many / to-one relationship as you'd expect. My problem is that Department's custom -awakeFromInsert gets called, yet its -addEmployeesObject and -addEmployees methods don't ever get called. If I add employees in the app, it all works swimmingly, but my custom accessors aren't ever used. http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdTroubleshooting.html#//apple_ref/doc/uid/TP40002320-SW3 Custom relationship set mutator methods are not invoked by an array controller Problem: You have implemented set mutator methods for a relationship as described in “Custom To-Many Relationship Accessor Methods,” and have bound thecontentSet binding of an NSArrayController instance to a relationship (as illustrated by the Employees array controller in NSPersistentDocument Core Data Tutorial), but the set mutator methods are not invoked when you add objects to and remove objects from the array controller. Cause: This is a bug. Remedy: You can work around this by adding self to the contentSet binding's key path. For example, instead of binding to [Department Object Controller].selection.employees, you would bind to [Department Object Controller].selection.self.employees. mmalc ___ 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
Re: What classes have -init?
On Feb 11, 2010, at 12:08 pm, Gordon Apple wrote: My point was that if you could count on init being called internally and all you needed was to initialize some ivars, you could override init and not have to override the (sometimes more involved) designated initializer and possibly other initializers. You could still use the (superclass) designated initializer or a class-level instantiator without overriding it. Please read The Designated Initializer in http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocAllocInit.html, in particular the section starting Figure 3-3 Covering the Designated Initializer. mmalc ___ 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
Re: Core Data: Insert, Fetch, Re-Fetch. Same Object?
On Feb 10, 2010, at 7:07 pm, Jerry Krinock wrote: Yes, basically. There is only going to be one in-memory object at a time that represents the same managed object. It certainly seems to be sensible, but I just wish someone could find such documentation. I can't. Uniquing: http://developer.apple.com/Mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdGlossary.html#//apple_ref/doc/uid/TP40001651-TP1 http://developer.apple.com/Mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdFaultingUniquing.html#//apple_ref/doc/uid/TP30001202 From Core Data Basics http://developer.apple.com/Mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdBasics.html#//apple_ref/doc/uid/TP40001650 You may have more than one managed object context in your application. For every object in a persistent store there may be at most one corresponding managed object associated with a given context (for more details, see “Faulting and Uniquing”). mmalc ___ 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
Re: Hot to define a connection from source code?
On Jan 28, 2010, at 9:17 pm, Jonathan Chacón wrote: Could you tell me any example project where I examine the source code? If you want to do iPhone development, I suspect the most useful for you will be UICatalog: http://developer.apple.com/iphone/library/samplecode/UICatalog/index.html From the description: This sample is a catalog exhibiting many views and controls in the UIKit framework, along with their various properties and styles. If you need code to create specific UI controls or views, refer to this sample and it should give you a good head start in building your user interface. In most cases you can simply copy and paste the code snippets you need. When images or custom views are used, accessibility code has been added. Using the iPhone Accessibility API enhances the user experience of VoiceOver users. mmalc ___ 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
Re: Hot to define a connection from source code?
On Jan 29, 2010, at 10:32 am, B.J. Buchalter wrote: On Jan 29, 2010, at 1:05 PM, mmalc Crawford wrote: If you want to do iPhone development, I suspect the most useful for you will be UICatalog: http://developer.apple.com/iphone/library/samplecode/UICatalog/index.html [...] I was looking at that one too and was going to suggest it, but there are a lot of xib files in that project, and I thought that it might be a lot more complicated to parse out... The majority of the nib files contain either plain UIView instances or table views; as the sample code description implies, most of the specific UI controls or views are created in code. mmalc ___ 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
Re: NSSlider
On Jan 28, 2010, at 9:42 am, vincent habchi wrote: Check the continuous checkbox in IB (or set the object property of the same name) and your target will get called while the user drags, as soon as the position changes. Do not forget there are some pitfalls. For example, I bound a slider to the alpha value of a CALayer. I had to subclass it, because there is no way I found (except a custom NSValueTransformer) to get the slider return a float value from [0,1] instead of integers. A trivial test setting the limits of a slider's value to 0 and 1 and binding its 'value' to an object controller shows that the slider happily sends float values between 0 and 1... mmalc ___ 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
Re: UIButton's Sender Control Events
On Jan 24, 2010, at 10:27 am, Chunk 1978 wrote:
refactoring code so one method for the same button can handle a small
if/else statement could easily be considered more ideal than having
two separate methods.
No, it couldn't. If you have different actions that should happen in response
to different control events, then the trivial thing to do is to implement
different methods for each.
i understand your concern, but you haven't provided an answer.
You haven't provided a good problem statement or description of why you want to
do something that runs counter to the common Cocoa pattern. In particular, in
the original post:
-(IBAction)myButton:(id)sender
{
if (sender.UIControlEvent =
forControlEvents:UIControlEventTouchUpInside) NSLog(@touchUp);
}
It's really not helpful to post code that is obviously neither code that you
could possibly be using in an application nor flagged as pseudo-code. What is
this snippet supposed to convey?
See also http://catb.org/~esr/faqs/smart-questions.html.
in fact, i've searched for hours and i can't find an answer.
Where have you looked, and for what?
at this point i'm wondering if it's even possible.
Shouldn't this rather suggest that one method for the same button can handle a
small if/else statement might not be considered more ideal than having two
separate methods?
mmalc
___
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
Re: NSDictionary trouble
On Jan 19, 2010, at 5:50 pm, Jeff Laing wrote: Yes, and it autoreleases it too. :-o That means it'll conveniently be released later on, which is exactly what you're running into. If you want to keep a reference to the dictionary, you should call alloc and init yourself. No, you should just *retain* the result of dictionaryWithCapacity. No, you shouldn't. If you're writing an init method and want to assign the dictionary to an instance variable, you should use alloc/init. If you want to assign the dictionary to an instance variable, you should use an accessor method. In this case, it's still better to use alloc/init then release the dictionary when you've finished with it. If you want to create the dictionary, use it temporarily, then forget about it, then dictionaryWithCapacity is OK, but again (particularly on iPhone) best practice is still to use alloc/init+release. mmalc ___ 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
Re: NSDictionary trouble
On Jan 19, 2010, at 8:47 pm, Jeff Laing wrote:
I wrote:
No, you should just *retain* the result of dictionaryWithCapacity.
mmalc wrote:
No, you shouldn't.
With all due respect, why not?
Because it's difficult to imagine a common situation in which your advice will
be valid, for example:
NSMutableDictionary *dict = [NSMutableDictionary
dictionaryWithCapacity:x];
// Add to the dictionary.
myInstanceVariable = [dict retain];
Wrong, because you're setting an instance variable directly instead of using an
accessor.
NSMutableDictionary *dict = [[NSMutableDictionary
dictionaryWithCapacity:x] retain];
// Use the dictionary.
[dict release];
Retaining the dictionary is pointless.
Apple gives us all those convenience methods but you say we shouldn't use
them?
Please don't misrepresent what I wrote. I didn't say that. There are situations
in which the convenience API is useful and not discouraged. In particular, for
example, if you're creating a dictionary as a return value from a method, then
it's perfectly reasonable to use a convenience method:
- (NSDictionary *)dictionaryRepresentation {
NSMutableDictionary *dict = [NSMutableDictionary
dictionaryWithCapacity:5];
// Use the dictionary.
return dict;
}
(Also if you're using garbage collection, any of the convenience methods are
perfectly reasonable.)
In most other cases, however, Jens and Ken have already addressed the principal
issue: performance. You don't want to needlessly prolong the lifetime of
objects.
If you want to assign the dictionary to an instance variable, you
should use an accessor method. In this case, it's still better to use
alloc/init then release the dictionary when you've finished with it.
That's seems a really aberrant case, where you are creating an empty
dictionary with a nominated capacity. I can't visualize a case where you
would do such a thing, outside of the initialiser.
This pattern is shown commonly in iPhone sample code:
NSMutableDictionary *aDictionary = [[NSMutableDictionary alloc]
initWithCapacity:x]
// Add to the dictionary.
self.dictionary = aDictionary;
[aDictionary release];
There are cases like the NSFileManager where you need to pass in a dictionary
of options that describe the directory being created (for example) - should I
really be creating temporary variables for those, or using the convenience
methods (dictionaryWithObject:forKey:)?
The same applies as above.
Following best practices, you should use alloc/init+release. How important this
is to adhere to depends on how performance-sensitive your code and platform
are...
To reiterate Jens' succinct formula:
Convenience ≠ performance.
mmalc
___
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
Re: Adding to-many objects programmatically
On Jan 16, 2010, at 12:17 am, Roland King wrote: Cast to the actual type before calling the method. Instead of [ managedObject method1 ] do [ (Employee*)managedObject method1 ] No; the OP stated, I don't use custom classes, so this won't work. Follow the pattern described in the documentation: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdAccessorMethods.html#//apple_ref/doc/uid/TP40002154-SW1 mmalc ___ 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
Re: Adding to-many objects programmatically
On Jan 15, 2010, at 8:52 pm, Jenny M wrote: but I don't know about the code... Modifying to-many relationships is described here: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdUsingMOs.html#//apple_ref/doc/uid/TP40001803 What did you try that didn't work? mmalc ___ 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
Re: Adding to-many objects programmatically
On Jan 15, 2010, at 10:00 pm, Jenny M wrote: I guess my question is also, was there any easier way to do it?? Is that how it's normally done? It's not clear exactly what you're referring to. Do you mean, is the typical pattern that which you described earlier, namely: I've been setting it using key-value coding: [object setValue:mySet forKey:categories] No, that's not how the documentation recommends that you do it. Core Data automatically generates efficient public and primitive get and setaccessor methods for modeled properties (attributes and relationships) of managed object classes (see “Managed Object Accessor Methods”). When you access or modify properties of a managed object, you should use these methods directly. [...] Typically, however, you do not want to set an entire relationship, instead you want to add or remove a single element at a time. To do this, you should use mutableSetValueForKey: or one of the automatically-generated relationship mutator methods (see “Dynamically-Generated Accessor Methods”): mmalc ___ 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
Re: Adding to-many objects programmatically
On Jan 15, 2010, at 10:57 pm, Jenny M wrote: The objects do load, I ran the program regardless of warnings and it did set the categories and references. So, how would I get it to build without those warnings? All of this is covered in the documentation: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdAccessorMethods.html#//apple_ref/doc/uid/TP40002154-SW1 mmalc ___ 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
Re: Bindings Problem
On Jan 14, 2010, at 3:11 pm, Carter R. Harrison wrote: In the addValueToSet: method I have the following code: - (IBAction)addValueToSet:(id)sender See http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/Troubleshooting.html#//apple_ref/doc/uid/TP40002148 mmalc ___ 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
Re: Bindings; Was: whether property in Cocoa class is KVO-compliant?
On Jan 11, 2010, at 9:01 am, Jerry Krinock wrote: I wonder why bindings was not as an extension of KVO, instead of as a separate sideshow. The effect is the same as KVO, It's not at all. Bindings uses KVO to ensure that things are kept synchronised; KVO is a general mechanism that allows one object to receive a notification when the value of a property changes. What it does in response is entirely up to it. mmalc ___ 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
Re: programatically updating UI for NSArrayContoller/NSTableView combo
On Jan 10, 2010, at 4:57 am, Quincey Morris wrote: I'm not sure where to go next with this ... I would strongly recommend dispensing with bindings for the moment: it's not an entry-level technology; it depends on an understanding of the fundamentals of Cocoa development including object graph management, key-value coding, and key-value observing. I would suggest that it's more fruitful and less frustrating to continue to gain experience by building simpler applications that use the traditional target-action and delegate/datasource patterns, then to return to bindings once you've mastered those. mmalc ___ 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
Re: How to know whether property in Cocoa class is KVO-compliant?
On Jan 10, 2010, at 8:18 pm, Dave Fernandes wrote: Look for Cocoa Bindings Guide in the docs. It would be nice if it were cross-referenced in every class description. SelectedIndex should work for a segmented control. Haven't tried it myself though. No; the Cocoa Bindings Reference doesn't catalogue KVO compliance, it lists bindings. In general, controller objects observe model objects, and views observe controllers and models -- you typically don't bind to views. Thus you shouldn't generally expect views' properties to be observable. mmalc ___ 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
Re: programatically updating UI for NSArrayContoller/NSTableView combo
On Jan 9, 2010, at 1:50 pm, Russell Gray wrote: On 10/01/2010, at 8:18 AM, Quincey Morris wrote: How about if you register your own KVO observer of the subscriptions property? Does it get notified when the property changes? Did you check the log for exception error messages? So, I added an observer to my awakeFromNIb: [subscriptionsArrayController addObserver: self forKeyPath: @arrangedObjects options: NSKeyValueObservingOptionNew context: NULL]; Quincey did suggest observing the subscriptions property... what would be my next plan of attack here? Re-read the KVO Programming Guide and the Cocoa Bindings Programming Guide, and review the myriad examples that show how to do this to see how yours differs. Seeing the code you're using to modify the subscriptions property would also be useful. mmalc ___ 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
Re: programatically updating UI for NSArrayContoller/NSTableView combo
On Jan 9, 2010, at 2:15 pm, Russell Gray wrote:
[subscriptionsArray addObject:output];
You haven't shown where you're modifying 'subscriptions' (apart from in the
init method).
Do you have two arrays that mirror each other, subscriptions and
subscriptionsArray?
Otherwise, if this is a typo (and it's helpful to see the code you're actually
using...), then:
On Jan 9, 2010, at 3:29 am, Quincey Morris wrote:
There are two ways you can update the subscriptions property
KVO-compliantly:
you (Russell) still don't seem to have followed this advice...
Some of the rest of the code seems somewhat confused. For example:
int i = 0;
for (NSDictionary *child in subscriptionsArray)
{
NSDictionary* subscriptionsDictionary =
[subscriptionsArray objectAtIndex:i];
SubscriptionInfo* subscriptionInfo =
[[[SubscriptionInfo alloc] initWithInfoDictionary: subscriptionsDictionary]
autorelease];
[subscriptions addObject: subscriptionInfo];
i++;
}
What is the point of the unused child iterator variable? Should your code not
look more like:
for (NSDictionary *child in subscriptionsArray)
{
SubscriptionInfo* subscriptionInfo =
[[SubscriptionInfo alloc] initWithInfoDictionary:child];
[subscriptions addObject: subscriptionInfo];
[subscriptionInfo release];
}
mmalc
___
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
Re: if statement causing 32 Byte leak?
On Jan 9, 2010, at 6:34 pm, Graham Cox wrote: 'string' does not contain 'new', 'alloc' or 'copy' therefore you do not own it. That summary is just very subtly wrong(*), which is why people are generally discouraged from paraphrasing the rules. That said, there is indeed really very little to remember: http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html#//apple_ref/doc/uid/2994 mmalc Hint: See http://developer.apple.com/mac/library/documentation/Cocoa/Reference/CoreDataFramework/Classes/NSEntityDescription_Class/NSEntityDescription.html#//apple_ref/occ/clm/NSEntityDescription/insertNewObjectForEntityForName:inManagedObjectContext: ___ 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
Re: programatically updating UI for NSArrayContoller/NSTableView combo
On Jan 8, 2010, at 1:10 pm, Russell Gray wrote: I am having trouble trying to get a tableView to update its contents, when bound to an NSArrayController - but only when new objects are added. removal, and updating of current objects works fine. http://homepage.mac.com/mmalc/CocoaExamples/controllers.html Programmatic modifications to arrays not noticed by table view mmalc ___ 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
Re: NSDate without time portion
On Jan 5, 2010, at 12:40 pm, Robert Claeson wrote: (Greenwich, the G in GMT, is in North London) Well, if we're being pedantic, South East of London, actually... http://maps.google.com/maps?f=qsource=s_qhl=engeocode=q=51.477811,+0.0sll=51.477211,-0.000297sspn=0.008326,0.009978g=51.477811,+0.0ie=UTF8ll=51.488652,-0.063515spn=0.133183,0.290451z=12 GMT is typically used to refer to UTC; in summertime, Britain's time zone is BST. http://en.wikipedia.org/wiki/Greenwich_Mean_Time mmalc ___ 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
Re: NSDate without time portion
On Jan 5, 2010, at 1:35 pm, Kyle Sluder wrote: On Tue, Jan 5, 2010 at 1:23 PM, mmalc Crawford mmalc_li...@me.com wrote: An NSDate object represent a single point in time -- you can think of it basically as a wrapper for an NSTimeInterval from the reference date. If you want to create components from the date, then you must do so with respect to a particular calendar *and time zone*... This is of course possible, but then you have to be careful about always using the same combination of calendar and time zone to create the components and recreate the date from the components. I believe that Quincey's argument is that it is conceptually inaccurate in most cases to think of a point in time as simply an interval from a reference date. I agree that in contexts where words like today are meaningful, he's probably right. Especially in calendaring/scheduling apps. Given the number of people who struggle with the concept of daylight saving time, I am not surprised that I have yet to meet a non-technical person who could conceptualize a point in time independently of a calendar system. I'm not sure what the point is here, though? It's the job of the application to present to the user a representation of a date that they can understand. It's the job of the programmer to interpret that unambiguously such that it can be stored and recreated -- which is the issue here. Talking about date components in the abstract as if any date can arbitrarily be reduced to a collection of components without reference to any other context (the calendar and time zone) is misleading. mmalc ___ 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
Re: Merging changes across NSManagedObjectContexts
On Dec 30, 2009, at 12:54 pm, Rick Mann wrote: In my app I have a situation where I have two (Core Data) documents open, and I need to merge all the changes made in one doc1 to the changes in doc2. I've been reading the section on Change Management in the Core Data Programming Guide, but it just talks about the caveats and gotchas, and doesn't actually talk about how to effect the merge. It also only talks about the example where the two MOCs share a single file, which is not the case here. Then you're not merging, you're copying/moving objects from one store to another. mmalc ___ 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
Re: Merging changes across NSManagedObjectContexts
On Dec 30, 2009, at 1:58 pm, Rick Mann wrote: Is that operation discussed in the docs somewhere? Yes. http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/cdProgrammingGuide.html#//apple_ref/doc/uid/TP30001200 mmalc ___ 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
Re: Merging changes across NSManagedObjectContexts
On Dec 30, 2009, at 2:24 pm, Rick Mann wrote: It's pretty much the same as any other operation on with a MOC. You cannot copy or move a managed object from one MOC to another in a simple fashion. Instead, you have got to create new, corresponding objects in the second MOC, and then (if needed) delete the old objects from the first MOC. Really? There's no way to associate the MOC with the persistent store of an existing doc, and then do a save operation, and have the objects transferred automatically? No, really, there isn't. Really. Because it seems like Core Data supports creating a second MOC on an existing persistent store and then saving. You're describing two completely different operations. Copying a record from one store to another is not the same as having representations of a given record in two contexts. mmalc ___ 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
Re: Merging changes across NSManagedObjectContexts
On Dec 30, 2009, at 2:08 pm, Mike Abdullah wrote: It's pretty much the same as any other operation on with a MOC. You cannot copy or move a managed object from one MOC to another in a simple fashion. Instead, you have got to create new, corresponding objects in the second MOC, and then (if needed) delete the old objects from the first MOC. Given the introductory clause (It's pretty much the same as any other operation on with a MOC), this is potentially misleading. This applies to the specific case where you want to move data from one store to another. For typical operations with a context, you don't want to move records between stores. If you're using multiple contexts, the more likely scenario is that you have a realisation of a given record in one context and you want another realisation of the same record in another context. For that you do not *create* new objects in the second context (and you don't *delete* the old objects in the first context); instead you ask the context for a managed object using objectWithID: or similar. mmalc ___ 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
Re: Creating CoreData classes
On Dec 27, 2009, at 9:07 pm, Jim Correia wrote: On Dec 27, 2009, at 11:52 PM, Brian Bruinewoud wrote: If I've generated core data classes from my model, how do I use them to create new values? Currently I'm doing this: CDClass *cdObject = (CDClass *)[ NSEntityDescription insertNewObjectForEntityForName: @CDClass inManagedObjectContext: context ]; This is in fact the correct idiom for doing this. ... as described in: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdCreateMOs.html#//apple_ref/doc/uid/TP40001654 ___ 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
Re: Releasing Objects
On Dec 22, 2009, at 9:40 pm, Michael Craig wrote: At the point where the tutorial discusses garbage collection (end of ch. 5), I decided to implement the deallocation of the Converter objects created by ConverterController's convert: method. I want the deallocation to happen inside convert:. To test it, I'm using [converter retainCount], thinking that after the object is deallocated, that call will cause an error. This is the wrong way to think about memory management. You shouldn't be thinking in terms of deallocating another object, only in terms of ownership. You want to relinquish ownership of an object when you've finished with it. This is discussed in greater detail in http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.html#//apple_ref/doc/uid/2043 and the memory management rules summarised in http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html#//apple_ref/doc/uid/2994. To elaborate on bbum's messages, the documentation for retainCount is quite explicit... http://developer.apple.com/mac/library/documentation/Cocoa/Reference/Foundation/Protocols/NSObject_Protocol/Reference/NSObject.html#//apple_ref/occ/intfm/NSObject/retainCount mmalc ___ 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
Re: Autorotation for a subview
On Dec 22, 2009, at 3:37 pm, Matt Neuburg wrote:
This sounds like a good time for the view to post an NSNotification. The
subview can then respond to it. m.
Sounds like overkill --- swatting mosquitoes with sledgehammers.
An NSNotification is not a sledgehammer. And letting interested listeners
know that a certain key moment in the lifetime of the application has been
reached, is not a mosquito. Indeed, this is why something like
UIApplicationDidFinishLaunchingNotification *is* a notification. Sometimes
the delegate or subclass instance is not the only interested party; the
moment where didRotateFromInterfaceOrientation: arrives might be such a case.
Using a notification per se is not a sledgehammer.
Setting up your own view to post notifications for this situation, however,
almost certainly is (*insofar as it's possible to determine the OP's
requirements, given the confused problem description...*).
There is already a perfectly good mechanism for communicating changes about a
device's orientation through an object that's in the best place to respond to
such changes -- UIView*Controller*'s
willAnimateRotationToInterfaceOrientation... et al. methods.
On Dec 22, 2009, at 4:25 pm, Eric E. Dolecki wrote:
I am interested in NSNotification as I haven't used that yet.
It's not clear if you're trying to solve a problem or learn about iPhone OS
programming in general.
Unthinkingly chasing interesting API is not a particularly useful strategy
for solving a problem.
Per Henry's reply, you should properly describe what the task is you're trying
to accomplish using terminology and conventions that will best help those
trying to help you.
Hint; this:
- (IBAction) displayInfo:(id)sender {
myInfoView = [[InfoViewController alloc] initWithNibName:@InfoViewController
bundle:[NSBundle mainBundle]];
myInfoView.view.autoresizingMask = (UIViewAutoresizingFlexibleLeftMargin |
UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleTopMargin
| UIViewAutoresizingFlexibleBottomMargin);
[self.view addSubview:myInfoView.view];
}
makes almost no sense.
Using a view controller to instantiate a view to add as a subview of another
view that is presumably managed by another view controller is not a supported
pattern. You're also ignoring basic memory management guidelines, and will
almost certainly be leaking both the view controller and its accompanying view.
Adding notifications to this scenario will not end prettily.
mmalc
___
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
Re: Autorotation for a subview
On Dec 22, 2009, at 5:09 pm, Eric E. Dolecki wrote: I already stated (I believe) that I needed to redo the way this application is being constructed. In this way I'll have more direct access to subviews. I originally created another view controller with it's own nib and I was indeed loading it and using it as a subview to my main view. No leaks since it's removed itself from superview. If you're using the code as shown, I can almost guarantee you will be leaking. You don't show any code for releasing any previous instance of the view controller, so you'll be leaking that and so also its view. Please review: http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html, and in particular Using Accessor Methods at http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html#//apple_ref/doc/uid/TP40004447. And again, this is not how view controllers are intended to be used -- see http://developer.apple.com/iphone/library/featuredarticles/ViewControllerPGforiPhoneOS/Introduction/Introduction.html In regards to the NSNotification, I look at that as a learning opportunity and not merely a way of throwing some code at a problem hoping it will make it work. I haven't ever used it before - I've only been part-timing iPhone apps for about 7 months now. It's fascinating and exciting and humbling when you're trying to do something and were unaware of the proper framework or methods to use. A desire to learn is certainly an admirable trait. Given that the actual problem is still ill-specified, however, focussing on solving that issue would seem a more profitable strategy for now... mmalc ___ 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
Re: Core Data Migration
On Dec 20, 2009, at 11:40 pm, Chaitanya Pandit wrote: One weird thing that is happening is that just after the configurePersistentStoreCoordinatorForURL... call, the contents of my document on the disk are changed, even if i didn't save the document It's not clear in what sense this is weird? This is expected behaviour... On Dec 21, 2009, at 5:56 pm, Jerry Krinock wrote: But something else should happen, which is that, if the filename is, for example, SomeDoc.myapp, the original file will be copied to SomeDoc~.myapp. Note the tilde. I've never seen this documented anywhere, though. If the migration proceeds successfully, the existing store at storeURL is renamed with a “~” suffix before any file extension and the migrated store saved to storeURL. http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/vmInitiating.html#//apple_ref/doc/uid/TP40005509 mmalc ___ 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
Re: UIDatePicker in landscape - displaying items moving into position weirdness
On Dec 11, 2009, at 1:06 pm, Alex Kac wrote:
if (timeSpanPicker)
{
//remove it
[timeSpanPicker removeFromSuperview];
[timeSpanPicker release];
//now add it again
[self createRelativeTriggerTimeSpanPicker];
}
I would strongly suggest replacing
[timeSpanPicker release];
with
[self setTimeSpanPicker:nil];
This is generally better form for memory management.
Generally direct assignment is discouraged anywhere other than in initialiser
methods, so I'd also suggest replacing
timeSpanPicker = [[UITimeSpanPicker alloc] initWithFrame: CGRectZero];
with something more like:
UITimeSpanPicker *aTimeSpanPicker = [[UITimeSpanPicker alloc]
initWithFrame: CGRectZero];
self.aTimeSpanPicker = aTimeSpanPicker;
[aTimeSpanPicker release];
mmalc
___
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
Re: Additional action when a view's value changes (Cocoa Bindings)
On Dec 9, 2009, at 5:47 am, Christian Ziegler wrote: Sorry I got to correct myself, it's not Cocoa Bindings, but direct target/action. So I connected the takeIntegerValue action of both views to each other in contrast to connecting it to a controller. Don't do that. Both should invoke an action in a controller, which may then update views and models appropriately. You should read http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/ and in particular The Model-View-Controller Design Pattern http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html#//apple_ref/doc/uid/TP40002974-CH6-SW1 which is crucial for all Cocoa development. mmalc ___ 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
Re: Tracking Multiple Touches For Appropriate Label
On Dec 7, 2009, at 7:08 pm, Chunk 1978 wrote: is this suppose to work for multiple touches where one touch is already present, then another touches the screen? Yes, it does; tested in a working application. it's not working for me. each time i touch the screen and add an object to the myTouches array the return count always returns 1, no matter how many fingers i already have touching the screen. Then despite your original assertion, it is likely that you haven't set multipleTouchEnabled on your view. mmalc ___ 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
Re: Tracking Multiple Touches For Appropriate Label
On Dec 8, 2009, at 12:38 am, mmalc Crawford wrote: is this suppose to work for multiple touches where one touch is already present, then another touches the screen? Yes, it does; tested in a working application. it's not working for me. each time i touch the screen and add an object to the myTouches array the return count always returns 1, no matter how many fingers i already have touching the screen. Then despite your original assertion, it is likely that you haven't set multipleTouchEnabled on your view. I misread the reply. Per the documentation for touchesBegan:withEvent:, touches A set of UITouch instances that represent the touches for the starting phase of the event represented by event. http://developer.apple.com/iphone/library/documentation/UIKit/Reference/UIResponder_Class/Reference/Reference.html#//apple_ref/occ/instm/UIResponder/touchesBegan:withEvent: (see also http://developer.apple.com/iphone/library/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/EventHandling/EventHandling.html#//apple_ref/doc/uid/TP40007072-CH9-SW15). If you already have one finger touching the screen, and you add another, then 'touches' will only contain one touch. If you want the coordinates of all the current touches that happen to be present when another touch is added, then you need to get allTouches from the event. mmalc ___ 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
Re: Tracking Multiple Touches For Appropriate Label
On Dec 8, 2009, at 3:49 am, Chunk 1978 wrote: i meant that i find it complicated compared to basic single touches or gestures. It's not clear what's complicated. You typically want to know when touches began, moved, and ended, and there are methods to inform you when each of these things happen (and another to let you know that they've been interrupted). This is a multi-touch system, so just because one touch began it doesn't mean all did. So in some cases at least (including, it seems, yours) you need a means to get information about other touches. The methods therefore all tell you: Here are the touches that have just entered the phase you're interested in in this method, and here's a data structure (the UIEvent object) that gives you a way to get information about all the current touches. It's difficult to see how this could be simpler. About the only simplification could be that the methods could take a single parameter... there are a couple of scenarios for this. The methods could just pass the UIEvent object -- but then you'd have to iterate through its touches to find the ones that are in the phase you're interested in. Or you could have two (or three) methods per phase, e.g. touchesBegan: and touchesBeganInEvent: (and maybe again touchesBegan:withEvent:), but then you're making things more complicated again with multiple override points. mmalc ___ 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
Re: Tracking Multiple Touches For Appropriate Label
On Dec 8, 2009, at 8:59 am, Chunk 1978 wrote:
this is what i have so far, but i have no idea how to write the
touchesEnded method so that the appropriate label will clear. so if 3
fingers are touching the screen and displaying their different
coordinates, if the 2nd finger that was pressed ends its touch, the
2nd label will clear (Touch 2: {0, 0}) while the 1st and 3rd
continue to track. clearly i'm lost, i apologize.
[...]
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
for (UITouch *touch in touches)
[touchesArray addObject:touch];
Touches are delivered in mathematical sets; there is no ordering. It's not
quite clear what you're trying to achieve by adding the touches to the array,
but it won't preserve ordering for you over the long term. A user may make one
touch, then put down another finger, lift the first, then put down a third
whilst the second is still on screen. Is that now touch 1 or touch 3? (UIKit
happens to recycle touch objects, but it's not clear if that's the same
semantic you want.)
(As an aside, note also NSSet's initWithArray: method...)
It's still not clear precisely what you want to achieve (see
http://catb.org/~esr/faqs/smart-questions.html#goal). Generally, though, you
seem to want a mapping from a touch to a particular label to display the
current coordinates, along the lines of the class below...
mmalc
#import UIKit/UIKit.h
#import CoreFoundation/CoreFoundation.h
@interface TouchesView : UIView {
UILabel *touchLabel1;
UILabel *touchLabel2;
UILabel *touchLabel3;
UILabel *touchLabel4;
UILabel *touchLabel5;
CFMutableDictionaryRef touchToLabelMapping;
NSMutableArray *availableLabels;
BOOL setUp;
}
@property (nonatomic, retain) IBOutlet UILabel *touchLabel1;
@property (nonatomic, retain) IBOutlet UILabel *touchLabel2;
@property (nonatomic, retain) IBOutlet UILabel *touchLabel3;
@property (nonatomic, retain) IBOutlet UILabel *touchLabel4;
@property (nonatomic, retain) IBOutlet UILabel *touchLabel5;
@end
@implementation TouchesView
@synthesize touchLabel1, touchLabel2, touchLabel3, touchLabel4, touchLabel5;
- (void)setUpTouchHandling {
touchToLabelMapping = CFDictionaryCreateMutable (kCFAllocatorDefault, 5,
kCFTypeDictionaryKeyCallBacks, kCFTypeDictionaryValueCallBacks);
availableLabels = [[NSMutableArray alloc] initWithObjects:touchLabel1,
touchLabel2, touchLabel3, touchLabel4, touchLabel5, nil];
}
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
if (!setUp) {
[self setUpTouchHandling];
}
for (UITouch *touch in touches) {
if (touch.view == self) {
UILabel *label = (UILabel *)[availableLabels objectAtIndex:0];
CFDictionaryAddValue (touchToLabelMapping, touch, label);
[availableLabels removeObjectAtIndex:0];
label.text = NSStringFromCGPoint([touch locationInView:self]);
}
}
}
- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event {
for (UITouch *touch in touches) {
if (touch.view == self) {
UILabel *label = (UILabel
*)CFDictionaryGetValue(touchToLabelMapping, touch);
label.text = NSStringFromCGPoint([touch locationInView:self]);
}
}
}
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {
for (UITouch *touch in touches) {
if (touch.view == self) {
UILabel *label = (UILabel
*)CFDictionaryGetValue(touchToLabelMapping, touch);
label.text = @{0, 0};
CFDictionaryRemoveValue (touchToLabelMapping, touch);
[availableLabels addObject:label];
}
}
}
- (void)dealloc {
CFRelease(touchToLabelMapping);
[availableLabels release];
[touchLabel1 release];
[touchLabel2 release];
[touchLabel3 release];
[touchLabel4 release];
[touchLabel5 release];
[super dealloc];
}
@end
___
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
Re: Tracking Multiple Touches For Appropriate Label
On Dec 8, 2009, at 12:33 pm, mmalc Crawford wrote:
Get the logic right...
- (void)setUpTouchHandling {
touchToLabelMapping = CFDictionaryCreateMutable (kCFAllocatorDefault, 5,
kCFTypeDictionaryKeyCallBacks, kCFTypeDictionaryValueCallBacks);
availableLabels = [[NSMutableArray alloc] initWithObjects:touchLabel1,
touchLabel2, touchLabel3, touchLabel4, touchLabel5, nil];
}
- (void)setUpTouchHandling {
touchToLabelMapping = CFDictionaryCreateMutable (kCFAllocatorDefault, 5,
kCFTypeDictionaryKeyCallBacks, kCFTypeDictionaryValueCallBacks);
availableLabels = [[NSMutableArray alloc] initWithObjects:touchLabel1,
touchLabel2, touchLabel3, touchLabel4, touchLabel5, nil];
setUp = YES;
}
... and improve the user experience accordingly:
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {
for (UITouch *touch in touches) {
if (touch.view == self) {
UILabel *label = (UILabel
*)CFDictionaryGetValue(touchToLabelMapping, touch);
label.text = @{0, 0};
CFDictionaryRemoveValue (touchToLabelMapping, touch);
[availableLabels addObject:label];
}
}
}
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {
for (UITouch *touch in touches) {
if (touch.view == self) {
UILabel *label = (UILabel
*)CFDictionaryGetValue(touchToLabelMapping, touch);
label.text = @{0, 0};
CFDictionaryRemoveValue (touchToLabelMapping, touch);
[availableLabels insertObject:label atIndex:0];
}
}
}
(I'm using setUpTouchHandling so that this will work however you configure your
view or view controller -- ideally you choose a more appropriate initialisation
locus.)
mmalc
___
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
Re: Binding and Observers
On Dec 8, 2009, at 2:17 am, Gerriet M. Denkmann wrote:
- (void)windowWillClose:(NSNotification *)notification
{
id f = [ ikView observationInfo ];
NSString *oi = [ f description ];
BOOL ok;
NSString *obs = @Observer:;
NSString *kpa = @Key path:;
unsigned long long uuu;
NSString *keyPath1;
NSScanner *u = [ NSScanner scannerWithString: oi ];
[ u setCharactersToBeSkipped: [ NSCharacterSet
whitespaceAndNewlineCharacterSet ] ];
ok = [ u scanUpToString: obs intoString: NULL ];
ok = [ u scanString: obs intoString: NULL ];
ok = [ u scanHexLongLong: uuu ];
ok = [ u scanUpToString: kpa intoString: NULL ];
ok = [ u scanString: kpa intoString: NULL ];
ok = [ u scanUpToString: @, intoString: keyPath1 ];
[ myIkView removeObserver: (id)uuu forKeyPath: keyPath1 ];
}
???!!
What's wrong with unbind:?
http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSKeyValueBindingCreation_Protocol/Reference/Reference.html#//apple_ref/occ/instm/NSObject/unbind:
mmalc
___
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
Re: Tracking Multiple Touches For Appropriate Label
On Dec 7, 2009, at 4:12 pm, Chunk 1978 wrote:
if ([[[event allTouches] anyObject] view] == self)
{
for (UITouch *touch in touches)
{
CGPoint touchPoint = [[touches anyObject]
locationInView:self];
switch ([touches count])
{
case 1: [self Touch1:touchPoint];
break;
This logic doesn't make sense at all.
Moreover the custom method doesn't follow any standard Cocoa naming conventions.
You probably want something more like:
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
NSMutableArray *myTouches = [[NSMutableArray alloc] initWithCapacity:5];
NSArray *myLabels = [[NSArray alloc] initWithObjects:touchLabel1,
touchLabel2, touchLabel3, touchLabel4, touchLabel5, nil];
UITouch *touch;
for (touch in touches) {
if (touch.view == self) {
[myTouches addObject:touch];
}
}
NSUInteger i, count;
count = [myTouches count];
for (i = 0; i 5; i++) {
UILabel *label = [myLabels objectAtIndex:i];
NSString *text = @;
if (i count) {
UITouch *touch = [myTouches objectAtIndex:i];
text = NSStringFromCGPoint([touch locationInView:self]);
}
label.text = text;
}
[myTouches release];
[myLabels release];
}
(First pass, there may be a better strategy, but at least this will work.)
mmalc
___
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
Re: Strings mangled on generalPasteboard
On Nov 23, 2009, at 8:54 am, Jens Alfke wrote: The Cocoa Pasteboard API has the annoying limitation that there is no standard, public data type for multiple URLs. This is no longer true with Mac OS X v10.6 and later -- you can write and read multiple URLs to and from to the pasteboard. e.g. [url pasteboardPropertyListForType:(NSString *)kUTTypeURL] and NSArray *newURLs = [pasteboard readObjectsForClasses: [NSArray arrayWithObject:[NSURL class]] options:[NSDictionary dictionary]]; mmalc ___ 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
Re: Strings mangled on generalPasteboard
On Nov 23, 2009, at 1:04 pm, Jens Alfke wrote: [url pasteboardPropertyListForType:(NSString *)kUTTypeURL] But that still only writes a single NSURL, right? How do you write multiple using that API? On Mac OS X v10.6 and later, you can write multiple items to a pasteboard, so you simply write as many URLs as you want. http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/PasteboardGuide106/Articles/pbConcepts.html#//apple_ref/doc/uid/TP40008101 mmalc ___ 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
Re: Programmatic Binding KVC KVO
On Nov 4, 2009, at 5:20 pm, Rob Keniger wrote: See mmalc’s Graphics Bindings sample: http://homepage.mac.com/mmalc/CocoaExamples/controllers.html Sometimes Cocoa can be overwhelming. This will help. Thank you so much. :) You might also find this blog post very helpful: http://www.tomdalling.com/cocoa/implementing-your-own-cocoa-bindings Rather more relevant, the documentation pretty-nuch explains the simpler of the two bound views in the Graphics Bindings example: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/HowDoBindingsWork.html#//apple_ref/doc/uid/20002373 Sample code just for the joystick view is also available: http://developer.apple.com/mac/library/samplecode/BindingsJoystick/ mmalc ___ 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
Re: Adding new Core Data objects through a form
On Oct 28, 2009, at 6:26 am, Martin Cote wrote: That said, the situation in this sample project is quite different. When they add an object, they actually add an empty object in an array controller. This is precisely what the example does not do. http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/NSPersistentDocumentTutorial/08_CreationSheet/creationSheet.html#//apple_ref/doc/uid/TP40001799-CH284-SW2 It creates a separate managed object context to allow a discrete set of edits to be made that don't affect the array controller or the document's main context (which avoids questions about other parts of your app—like entity mode array controllers—dealing with this transient object being created). The significant advantage of using an actual managed object is that you can then leverage bindings to invoke its native validation methods, ensuring consistency of business logic. mmalc ___ 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
Re: Preparing for MOM versioning in version 1
On Oct 26, 2009, at 9:00 am, Fritz Anderson wrote: I'm about to unleash a Core Data-based application, and I'm sure the schema will change in later versions. The Core Data Model Versioning and Data Migration Programming Guide seems to say that migrating a store from one version to another, at least in simple cases, is magical: The application embeds the historical MOMs, with one of them marked current, and when a store built to an earlier model is opened, it is (in SIMPLE cases) migrated to the current model. Is this the case? It's not clear what the question is. The implication appears to be that the documentation is simply presenting a fiction of functionality that's not actually present. It's not magical. Per the Guide (http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/vmLightweight.html#//apple_ref/doc/uid/TP40008426): To request automatic lightweight migration, you set appropriate flags in the options dictionary you pass inaddPersistentStoreWithType:configuration:URL:options:error:. You need to set values corresponding to both the NSMigratePersistentStoresAutomaticallyOption and the NSInferMappingModelAutomaticallyOption keys to YES... The (iPhone) PhotoLocations example (http://developer.apple.com/iphone/library/samplecode/PhotoLocations/) illustrates the feature. mmalc ___ 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
Re: 2 Questions about the project With and Without bindings
On Oct 23, 2009, at 5:27 pm, Ken Thomases wrote: Indeed, there are no dealloc methods in the entire sample, which makes it buggy. There should be one for the MyDocument and Bookmark classes. The bug is actually that, for some reason, the projects aren't marked as using garbage collection. They should be... Perhaps someone might file a report... mmalc ___ 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
Re: Sending a Selector to another Class.
On Oct 22, 2009, at 9:54 am, Jeff Johnson wrote: Ignore bbum. We hereby promise never to break == for SEL. (But SEL is not char*. We will break that.) And now that it's on the mailing lists, it can be considered part of Apple's official documentation. ;-) It already is: http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html#//apple_ref/c/func/sel_isEqual mmalc ___ 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
Re: Search on Core data Table issue?
On Oct 22, 2009, at 4:09 am, Matthew Lindfield Seager wrote: A reducing search is more commonly referred to as filtering. A google search should help you very quickly as this is very easy with core data bindings. The question is related to iPhone and NSFetchedRestultsController, therefore desktop bindings are irrelevant. On Oct 20, 2009, at 10:56 pm, Damien Cooke wrote: One of the big problems as I see it is going to be updating the interface to let it know what to present. I assume an alternative NSFetchedResultsController needs to be sent to the UITableView. No, but that points along the right lines... So here are my issues: 1) I assume I need to create a NSFetchedResultsController with only the correct items in it then tell the UITableView to use this as the dataSource and reload the table? 2) is there a better way than executing a full sorted fetch and removing those objects that do not conform. ie is there a way of doing a select where type fetch? The fetched results controller is particularly well-suited to managing sectioned data. In a search results table, you don't have sections, and moreover your results set is pretty much guaranteed to change on every use, so incurring the overhead of storing the results is a waste. Rather than using a fetched results controller, therefore, simply execute a standard fetch for at least the first search character, typically for subsequent characters you might do in-memory filtering of the first returned-array. mmalc ___ 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
Re: odd behavior with NSError?
On Oct 15, 2009, at 10:41 pm, Nathan Vander Wilt wrote:
Ouch. So the following pattern is incorrect?
NSError* internalError = nil;
(void)[foo somethingReturningBool:bar error:internalError];
if (internalError) {
// ...
}
http://developer.apple.com/mac/library/DOCUMENTATION/Cocoa/Conceptual/ErrorHandlingCocoa/CreateCustomizeNSError/CreateCustomizeNSError.html#//apple_ref/doc/uid/TP40001806-CH204-BAJIIGCC
Note: Cocoa methods that indirectly return error objects in the Cocoa error
domain are guaranteed to return such objects if the method indicates failure by
directly returning nil or NO. With such methods, you should always check if the
return value is nil or NO before attempting to do anything with the NSError
object.
mmalc
___
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
Re: Can I make custom pasteboard type for an object reference?
On Oct 14, 2009, at 5:21 PM, Rick Mann wrote: NSMutableData* data = [NSMutableData data]; [data appendBytes: self length: sizeof (self)]; Try using an NSValue: + (NSValue *)valueWithPointer:(const void *)aPointer archive then unarchive - (void *)pointerValue mmalc ___ 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
Re: Binding to values which aren't there
On Oct 9, 2009, at 3:17 PM, A B wrote: I have a situation in which I would like a column in a table that is bound to an NSArrayController to display information that isn't actually in the objects being represented, but is instead the result of an operation that involves a bit of data in that row's object and a separate bit of data in another object. Just implement the standard table view data source method for that column (don't establish a binding). mmalc ___ 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
Re: Core data - how to set string min max programmatically?
On Sep 16, 2009, at 3:56 PM, Leon Starr wrote: I have been creating my models programmatically and am wondering how to treat the min/max length fields for string attributes. I can't seem to find any corresponding programatic settings. (Also wondering if there is any effect to these settings). Been googling all over the place with no success. Does anyone know? http://developer.apple.com/mac/library/documentation/Cocoa/Reference/CoreDataFramework/Classes/NSPropertyDescription_Class/NSPropertyDescription.html#//apple_ref/occ/instm/NSPropertyDescription/setValidationPredicates:withValidationWarnings: For an example, see http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreDataUtilityTutorial/Articles/03_createModel.html#//apple_ref/doc/uid/TP40001800-CH219-TP9 . mmalc ___ 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
Re: CoreData Bug? (SQLite vs XML)
On Sep 13, 2009, at 9:14 AM, Milen Dzhumerov wrote:
-(void)awakeFromFetch
{
for(id base in [self relationship])
Log(@%@, base);
...
}
awakeFromFetch
[...]
Important: Subclasses must invoke super’s implementation before
performing their own initialization.
In what sense is the relationship not restored properly? Are you
simply seeing faults?
mmalc
___
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
Re: NSArrayController design/usage question
On Sep 6, 2009, at 10:00 AM, Steven Degutis wrote: For instance, if you have 2 genuine properties on your Person entity called firstName and lastName then you can create a fullName property on your Person class, and when firstName or lastName change, call -willChangeValueForKey: and -didChangeValueForKey: on fullName and then have your -fullName method return a concatenation of the first and last names. This is at best misleading. In this situation, you should typically not invoke the change notification methods yourself; instead, you should set up dependent keys as described in http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/KeyValueObserving/Concepts/DependentKeys.html#//apple_ref/doc/uid/20002179-BAJEAIEE mmalc ___ 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
Re: NSDictionary, allKeys and the NSAutoreleasePool
On Sep 3, 2009, at 7:56 AM, Scott Andrew wrote: As Cocoa documentation states all items returned from a message are autoreleased unless otherwise stated in the documentation for the API call. The documentation emphatically does not state that. The basic rules are given here: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html#//apple_ref/doc/uid/2994-BAJHFBGH The rest of the document gives further details. mmalc ___ 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
Re: Core Data completely unable to find the source object model for migration
On Aug 6, 2009, at 10:37 AM, Matteo Manferdini wrote: What I discovered is that in the first case the hashes are the same for the model and the store, while in the second case the model has lost a lot of metadata in the versioning process. Along with my entities there are also other entities listed in the hashes (to name a few: CalDAVCalendar, CalendarChangeRequest, LocalGroup, etc). These entities hashes are lost in the versioned model, while my entities hashes remain the same. Any idea of why this is happening? It seems to me that this is an XCode bug. It's unlikely to be a bug. When you merge your models at runtime, you're including models from other frameworks. Make sure you only include your app's model by specifying the main bundle in mergedModelFromBundles:... Which OS version are you using? mmalc ___ 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
Re: Core Data completely unable to find the source object model for migration
On Aug 4, 2009, at 11:20 PM, Matteo Manferdini wrote: I'm trying to run core data migration on the store of my app but it seems to be unable to find the source object model no matter what. What happens if you don't try to perform migration and instead simply open the existing store with the first version model in your project? What happens if you try to open the existing store using the original version of your application (with the first version model)? It sounds like whatever v1 model you have in your v2 project isn't the same as the original v1 model. Have you changed it in some way? mmalc ___ 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
Re: Disabling Undo in Core Data
On Aug 1, 2009, at 5:11 AM, Squ Aire wrote: 1) In awakeFromNib, call either [[self managedObjectContext] setUndoManager:nil]; or [[[self managedObjectContext] undoManager] disableUndoRegistration]; This certainly works, but the problem with this is that the NSManagedObjectContextObjectsDidChangeNotification will stop being sent when the context changes! It's not clear why you make this assertion? A simple test shows this is not the case... Did you register for NSManagedObjectContextObjectsDidChangeNotification or @NSManagedObjectContextObjectsDidChangeNotification? mmalc ___ 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
Re: When saving the managed object context
On Jul 22, 2009, at 7:22 AM, Squ Aire wrote: How can I do some custom stuff before my NSManagedObjectContext saves? Register for NSManagedObjectContextWillSaveNotification. mmalc ___ 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
Re: When saving the managed object context
On Jul 22, 2009, at 8:05 AM, Squ Aire wrote: On Jul 22, 2009, at 7:22 AM, Squ Aire wrote: How can I do some custom stuff before my NSManagedObjectContext saves? Register for NSManagedObjectContextWillSaveNotification. I see no such thing in my docs. Only DidSave. Not WillSave. Sorry, I've got used to answering iPhone-related questions... mmalc ___ 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
Re: Core Data design patterns
On Jul 19, 2009, at 3:15 PM, Jerry Krinock wrote: The case in point here is that -[NSManagedObjectContext executeFetchRequest:error:] returns an NSError if something goes wrong. This is misleading. The fundamental behaviour is that method returns NO if something goes wrong. In addition, if the error parameter is non-NULL and something goes wrong, the parameter contains an NSError that describes the problem. mmalc ___ 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
Re: Core Data design patterns
On Jul 19, 2009, at 1:59 PM, Squ Aire wrote: * Finally an unrelated and basic Core Data question: Where do you paste the code you copy using the Copy Method Declarations/ Implementations feature in the data modeling tool? I really want to use those things because it is, according to docs, faster than valueForKey, setValueForKey, etc. Up until now, I have tended to make a subclass of each of my managed objects and pasted the declarations/implementations in there. Do you think this is a good idea? Yes, this is fine. If you really want to avoid multiple NSManagedObject subclasses, you may also create categories of NSManagedObject that declare the various properties, but in general I find that using custom classes feels better. mmalc ___ 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
Re: Core Data design patterns
On Jul 19, 2009, at 5:05 PM, mmalc Crawford wrote: The fundamental behaviour is that method returns NO if something goes wrong. As Jerry kindly pointed out off-list, this method of course returns nil -- not NO -- if something goes wrong. The important issue (and one which has given rise to several threads in the past, which is why the pattern warrants clarification) is that you should check the method's return value, not the error parameter, to determine whether the operation was successful. mmalc ___ 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
Re: Core Data debugging (Fritz Anderson)
On Jul 16, 2009, at 12:51 PM, tmow...@talktalk.net wrote:
I have removed it completely and just called the longer winded
[[NSApp delegate] managedObjectContext] when I need it. I suppose I
could have set the ivar in the awakeFromNib when all NIB objects are
guaranteed to have been instantiated.
In general, you are discouraged from retrieving resources such as this
from the application delegate. Instead, you should pass resources
directly to view controllers. This is the pattern shown in the Core
Data templates and related sample code, e.g.
- (void)applicationDidFinishLaunching:(UIApplication *)application {
RootViewController *rootViewController = (RootViewController *)
[navigationController topViewController];
rootViewController.managedObjectContext =
self.managedObjectContext;
[window addSubview:[navigationController view]];
[window makeKeyAndVisible];
}
This typically makes your view controllers more self-contained and
reusable.
mmalc
___
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
Terminating UIApplication and exit() (was Re: NSApplication and UIApplication)
On Jul 6, 2009, at 11:38 AM, DKJ wrote: I want to terminate my UIApplication under some specific error conditions. I'm used to doing this kind of thing using: [[NSApplication sharedApplication] terminate]; But docs don't show a terminate method for UIApplication. Apparently it will respond to the message regardless; however, I'm very wary of using it if neither the compiler nor the docs mention it. What should I do with UIApplication in these circumstances? (exit(0) seems a bit extreme.) Typically you should not offer an option to quit an iPhone application. It's up to the user to decide when they want to quit by pressing the Home button. This is a convenient time to mention the use of exit() in the Core Data application templates for iPhone. In defiance of the preceding comment, the templates use exit() precisely to indicate that you should do something at that point. If, for example, your application can't load the persistent store, then realistically your application cannot continue. If it does, then the user may or may not be able to use parts of the application, but whatever data they add or can edit will be lost, and the application will eventually fail in an odd way... So you should present an alert at that point, telling the user that the application cannot be used and that they should quit. mmalc ___ 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
Re: Is there any document to explain the process about the DepartmentAndEmployee code?
On Jul 6, 2009, at 8:20 PM, Bright wrote: And I find there are several sample code about Core Data, such as DepartmentAndEmployee and CoreRecipe But I don't know how these code were implemented step by step. Is there any document to show/explain the process to implement them concretely? http://developer.apple.com/documentation/Cocoa/Conceptual/NSPersistentDocumentTutorial/00_Introduction/introduction.html http://developer.apple.com/documentation/Cocoa/Conceptual/CoreDataUtilityTutorial/Articles/00_introduction.html http://developer.apple.com/iphone/library/documentation/DataManagement/Conceptual/iPhoneCoreData01/Introduction/Introduction.html mmalc ___ 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
Re: EXC_BAD_ACCESS on returning an int?
On Jul 4, 2009, at 5:39 PM, Ian Havelock wrote:
For future reference, in many cases EXC_BAD_ACCESS can be indicative
of a memory management problem. Here, however, you are asking NSLog
to print int values as objects ('%@' is the format specifier for an
object):
NSLog(@Number of Sides: %@, Min: %@, Max: %@, [poly1
numberOfSides], [poly1 minimumNumberOfSides], [poly1
maximumNumberOfSides]);
The runtime treats the integer as the address of an object and tries
to send it a message, which doesn't work out so well...
From http://developer.apple.com/documentation/Cocoa/Conceptual/Strings/Articles/formatSpecifiers.html#//apple_ref/doc/uid/TP40004265
, the specifier for an int is '%d', hence:
NSLog(@Number of Sides: %d, Min: %d, Max: %d, [poly1
numberOfSides], [poly1 minimumNumberOfSides], [poly1
maximumNumberOfSides]);
mmalc
___
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
Re: EXC_BAD_ACCESS on returning an int?
On Jul 4, 2009, at 11:43 PM, Andrew Farmer wrote:
- (int)numberOfSides {
return numberOfSides;
}
- (void)setNumberOfSides:(int)value {
numberOfSides = value;
}
Let me guess: does your stack trace (type tb in the gdb console)
indicate infinite recursion? Either synthesize accessors or write
your own - but don't try to do both at once. Down that road lies
madness.
This is not correct.
Certainly there is little point in using @synthesize if you're going
to implement both the getter and setter, however it is perfectly
reasonable to use @synthesize and still provide a custom
implementation of one of the methods. The instruction to the compiler
is to synthesize the methods *if it cannot find any other
implementation*.
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocProperties.html#//apple_ref/doc/uid/TP30001163-CH17-SW14
In the case of the implementations provided here, both of them are
valid and will not result in infinite recursion.
If the implementations had been:
- (int)numberOfSides {
return self.numberOfSides;
}
and/or
- (void)setNumberOfSides:(int)value {
self.numberOfSides = value;
}
then this would have resulted in infinite recursion.
mmalc
___
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
Re: Display either date part or time part in LOCAL format
On Jul 5, 2009, at 12:21 AM, Jacob Rhoden wrote: I am probably overlooking something obvious (I hope) but what is the proper way to convert. either the Date or Time part of an NSDate to a localised string? I know I can do the following but its not exactly localised :( NSDate *now = [[NSDate alloc] init]; NSDateFormatter *localDate = [[NSDateFormatter alloc] init]; [localDate setDateFormat:@-MM-dd]; NSString *date = [localDate stringFromDate:now]; What do you mean by it's not exactly localised? If you specify a format string that has localisable components, you'll see them, e.g. NSDate *now = [[NSDate alloc] init]; NSLocale *locale = [[NSLocale alloc] initWithLocaleIdentifier:@ar_OM]; NSDateFormatter *localDate = [[NSDateFormatter alloc] init]; [localDate setLocale:locale]; [localDate setDateFormat:@/MMM/dd]; NSString *date = [localDate stringFromDate:now]; date: ٢٠٠٩/يوليو/٠٥ (Note that the date separator is /.) Typically you're encouraged to use styles rather than specifying the format directly, since this takes the user's preferences into account -- see http://developer.apple.com/documentation/Cocoa/Conceptual/DataFormatting/Articles/dfDateFormatting10_4.html#//apple_ref/doc/uid/TP40002369-SW3 . mmalc ___ 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
Re: Yet another memory management question
On Jul 5, 2009, at 8:23 AM, Michael Ash wrote: It's the same benefit as anywhere else. You have two places, viewDidUnload and dealloc, which perform the exact same action. They do not perform the exact same action. In dealloc, you obviously relinquish ownership of all objects you own (and perhaps other resources). In viewDidUnload, you relinquish ownership of only those items that you can recreate later, if the view is loaded again. You typically do not, for example, relinquish ownership of any model objects. I *personally* suspect I'd find it easier to do a straightforward pass of each method to ensure they're correct rather than having to remember to create/update/check some other non-standard method each time I change the properties. YMMV. mmalc ___ 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
Re: Yet another memory management question
On Jul 4, 2009, at 8:11 PM, WT wrote:
The following is ok, though, assuming that you have appropriately
declared myObject in your class (for example, as an instance
variable):
- (void)viewDidLoad
{
myObject = [[NSObject alloc] init];
}
In general, this is not recommended.
If you manipulate an instance variable anywhere other than in an
initialiser or a dealloc method, you should use a suitable accessor
method.
- (void)viewDidLoad
{
id anObject = [[NSObject alloc] init];
[self setMyObject:anObject];
[anObject release];
}
Both are fine, but I would suggest something like the following,
just because it avoids code duplication:
- (void)viewDidUnload
{
[self dispose];
}
It is not clear here what is the benefit of avoiding code
duplication -- you're simply introducing another method that you have
to keep track of.
- (void)dealloc
{
[self dispose];
// deallocation of stuff that was not unloaded
[otherStuff release];
}
This is missing:
[super dealloc];
as the final statement;
- (void)dispose
{
[myObject release];
myObject = nil;
}
Again, you should use accessor methods rather than direct variable
manipulation.
You can have -dispose be a private method of your class so it won't
be accessible outside of it. One big advantage of this separation is
that if/when you need to change your deallocations, you only have to
do it in one place.
Referring to this as deallocations is at best misleading. The goal
is to relinquish ownership of any objects you're holding on to. This
may or may not result in deallocation of those objects.
mmalc
___
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
Re: Yet another memory management question
On Jul 4, 2009, at 9:31 PM, DKJ wrote: On 4-Jul-09, at 21:10 , mmalc Crawford wrote: you should use accessor methods rather than direct variable manipulation Would declaring all the variables as properties, and then synthesising them, take care of this? Strictly, this is an orthogonal issue. Declaring and synthesising properties creates the accessor methods; you still have to invoke them when appropriate. If so, what should I do in dealloc for those variables? For example, suppose I've got this in the header: NSArray *myArray; ... @property(retain) NSArray *myArray; And this in the implementation file: @synthesize myArray; Should dealloc have this: [myArray release]; or something like this: self.myArray = nil; In an initaliser method and in dealloc, you should typically set or release the variable directly, so in dealloc it would be [myArray release]; mmalc ___ 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
Re: Yet another memory management question
On Jul 4, 2009, at 9:40 PM, WT wrote:
In general, this is not recommended.
If you manipulate an instance variable anywhere other than in an
initialiser or a dealloc method, you should use a suitable accessor
method.
- (void)viewDidLoad
{
id anObject = [[NSObject alloc] init];
[self setMyObject:anObject];
[anObject release];
}
There is plenty of Apple sanctioned code that does not follow that
recommendation, both in sample code and in documentation.
Where instance variables are set without using accessor methods, this
should be regarded as a bug in the documentation or sample code and
reported.
Use of accessor methods is described plainly here:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html#//apple_ref/doc/uid/TP40004447-SW4
Indeed. That's the problem with copy/paste and doing things in Mail,
rather than from real code, ie, sometimes we all make silly
mistakes. Not an earth-shattering mistake to make in this list,
though, since you get a warning when trying to compile without the
call to super.
[...]
I think everyone understood what I meant. Sometimes I mess up
because of genuine confusion on my part and sometimes I mess up
because of multitasking. This time it was the latter.
These are two fundamental errors in a reply to a basic question about
the fundamentals of memory management.
As I've said on a previous occasion, over the decade and a half, I've
come increasingly to the opinion that many of the problems that people
have with memory management are not with the Basic Rules -- if they
find and read them, then people can usually understand and apply them
readily enough -- but with incomplete, inaccurate, and misleading
explanations of memory management given by their peers...
http://www.cocoabuilder.com/archive/message/cocoa/2008/12/26/226296
mmalc
___
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
Re: Design for custom tableviewcell button action
On Jul 3, 2009, at 11:54 AM, Brian Slick wrote:
So, if TaggedLocations was flying while mine was sucking, I'd
probably concede that what I was doing was wrong (and would probably
need more custom cells). But since neither one is performing very
well, and I can't find any significant differences between them, I'm
thinking there is either a flaw with this approach, or my trusty 1st-
gen just isn't bringing enough horsepower to handle it.
The only time you should see a performance hit with this approach is
when the cells are first loaded; once they're loaded (and cached),
performance should be identical whether you code the cell
programmatically or use a nib file. *Without looking at any
performance metrics* (I don't have a device to hand), I'd *guess* the
issue is likely to be with transparency. Try switching off
transparency wherever you can find it and see if that helps.
If you can exactly recreate your hand-coded cell in IB, it would be
interesting to see what the performance comparison is like.
I did make a slight adjustment to the technique - most significantly
the omitting of the identifier in the XIB file,
This is actually a very significant factor.
If you haven't set an identifier, it's not clear how you're retrieving
cached cells in tableView:cellForRowAtIndexPath:?
I assume you have a test along the lines of:
UITableViewCell *cell = [tableView
dequeueReusableCellWithIdentifier:CellIdentifier];
if (cell == nil) {
cell = ...
Could you check whether you're creating a new cell each time?
All this aside, please file a performance bug against the
TaggedLocations sample.
mmalc
___
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
Re: Design for custom tableviewcell button action
On Jul 3, 2009, at 2:45 PM, Brian Slick wrote:
So now I either need to figure out how to make my scenarios all work
with a single identifier, or I may just go ahead with the code-only
cell I just built in response to the performance issue. If would be
nice if there was some kind of queueWithReuseIdentifier: method for
these XIB cases.
Oh, you can have as many identifiers as you want.
For a nib-based approach, simply have as many nib files as you want --
where each nib file has a single cell but a different identifier --
and you probably(*) have an outlet for each type.
// Caveat: Typed in Mail
- (UITableViewCell *)tableView:(UITableView *)tableView
cellForRowAtIndexPath:(NSIndexPath *)indexPath {
if (condition1) {
static NSString *CellType1Identifier = @CellType1Identifier;
CellType1 *cell = (CellType1 *)[tableView
dequeueReusableCellWithIdentifier:CellType1Identifier];
if (cell == nil) {
[[NSBundle mainBundle] loadNibNamed:@CellType1 owner:self
options:nil];
cell = cellType1;
self. cellType1 = nil;
// configure cell ...
return cell;
}
if (condition2) {
static NSString *CellType12dentifier = @CellType12dentifier;
CellType1 *cell = (CellType1 *)[tableView
dequeueReusableCellWithIdentifier:CellType2Identifier];
if (cell == nil) {
[[NSBundle mainBundle] loadNibNamed:@CellType2 owner:self
options:nil];
cell = cellType2;
self. cellType2 = nil;
// configure cell ...
return cell;
}
// ...
(*) You wouldn't actually *need* a different outlet for each type,
since the outlet is used only very briefly for each load, and each
load happens sequentially, but you may prefer to identify each type
nevertheless.
Incidentally, that's what is wrong with TaggedLocations... it also
does not have the identifier in the XIB. I manually added it, then
retested, and saw dramatically better performance (for my own
program, too).
[...]
All this aside, please file a performance bug against the
TaggedLocations sample.
Done, although I'm not sure if I did so correctly. Thank you for
your help.
Ah, thanks.
If you could send the bug number, that would be useful.
mmalc
___
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
Re: in search of a starter iphone painting tutorial or sample code
On Jul 3, 2009, at 2:15 PM, colo wrote: I am seeking a bare bones beginner source or tutorial for building painting apps on the iphone. This one uses OpenGL: http://developer.apple.com/iphone/library/samplecode/GLPaint/ index.html You could use a similar technique to create CGPaths to represent the strokes, but performance with OpenGL is considerably better. mmalc ___ 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
Re: NSDateFormatter Breaks on non-English OS
On Jun 30, 2009, at 3:29 PM, Trygve Inda wrote: NSString* myDateFormat = @%a %b %e %H:%M:%S %Z %Y; NSDate*myDate = nil; // myDateString is Tue Jun 30 15:53:24 UTC 2009 myFormatter = [[NSDateFormatter alloc] initWithDateFormat:imageDateFormat allowNaturalLanguage:NO]; myDate = [myFormatter dateFromString:myDateString]; This works on my English OS, but if I set the Number format to German, myDate is nil. Why? It's not clear what you mean by setting the Number format. What value are you setting and where? If I am supplying the string format, and the string is correct, how do I fix it? Is it because Tue is English? Almost certainly -- Tue is not a German abbreviation... How can I force it to parse in English as my string will always be English? Do you need to support pre-10.4 systems? You are strongly encouraged to adopt the 10.4+ behaviour for formatters. You can then easily set a specific locale for the formatter. See http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/DataFormatting/Articles/dfDateFormatting10_4.html#//apple_ref/doc/uid/TP40002369 (note in particular the references to the Unicode string format standards). mmalc ___ 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
