I’m reading the Kindle edition of the book. In chapter 11, when setting the binding for the date picker, it helps to emphasize that the Date Picker Cell, not the Textual Date Picker With Stepper, should be bound to the Cars Array Controller. I made this error and it took me a couple of minutes to figure out.
A moment ago I have made the same mistake Thanks for your hint.
I second that. I also made that mistake and similarly did the same thing with the Level Indicator,which likewise needs to be bound to the cell.
I have got the same problem that the datePurchased field doesn’t shows the actual date, but I don’t think that your solutions are right in the sense of the book (even if it works fine). Remember that they wrote “you will never bind a cell”. And if you look at the example solution they don’t bind the the cell but the “Textual Date Picker With Stepper” - and it works. But I have to commit that I wasn’t able to find out why their solution works and mine doesn’t or only with binding to the cell.
So may be Adam could give us a hint.
it’s very interesting, after I read your post I changed my bindings and - oh wonder - now it works.
Maybe it was a problem of Xcode, I have no idea. So I think you are absolutely right.
You are the seeing man among blind ones Thanks for your post.
Sounds like there is some confusion around the use of the word cell. The book says in a few places: “never bind a cell”, which is true. But we do bind to view based table view cells. In the former case we are saying do not set bindings on a cell (where the cell is the cell of a control, NSCell subclass). In the latter case we are talking about binding to a value on the table view cell in which a control resides, specifically objectValue on that table view cell.
Cells (NSCell subclasses) are different from view-based table view cells (NSTableCellView)… unfortunate and confusing naming overlap.
Does this help make it more clear? If not, let me know what’s not clear and I’ll do my best to help.
thank you for your answer. The use of the terms is now clear so far. But the cause of the error is not clear to me yet. All of us here in the thread, followed your example in Chapter 11. Everything worked just fine. Then the program was expanded to include the automatic entry of the actual date. But this method didn’t worked for us. The method was just not called. MMagian from the first post, has solved the problem by binding the object called “date picker cell” and not the object “Textual Date picker with stepper” as you did in the example solution, that I downloaded from your page. I compiled your solution on my computer and it worked fine. But I couldn’t figure out the difference to my code which was only running with the bindings as MMagian did.
Now, when I solved the challenge suddenly my code worked with the same bindings as in the example code. So I don’t have any explanation what we did wrong before.
What I’ve observed is MyDocument.xib file doesn’t get grayed out when I do the proposed change. I mean, XCode doesn’t realize changing Array Controller to CarArrayController custom class. Then, changing other Interface Builder parts, sets MyDocument.xib as dirty and finally saved before compiling.
As a rule of thumb, always take a look to “Project Navigator” when editing files to check if XCode is aware of the change.
I had the same issue with the current date not showing up, and I am on Xcode v 4.2 by the way (maybe has something to do with it?). Anyway, the way I got it to work was bizarre, I added the initWithcoder method, then archived the application, then went back and deleted the initWithCoder method (going back to my original code), and now it works! It doesn’t make any sense to me, so I’ll assume it’s a bug…
I think it is a bug.
For my part I had the same issue. What I did was :
1 - on “Textual Date Picker With Stepper” > “Value” tab, I unchecked the “Bind to Cars” checkbox.
2 - CMD+Shift+K to clean the project
3 - CMD+Shift+B to build the project
4 - Run it and close it
5 - Back on “Textual Date Picker With Stepper” > “Value” tab, I checked the “Bind to Cars” checkbox.
6 - Repeated step 2 to 4 then it worked…
Be sure that the class of your “Cars” controller is set to
I think I have correctly considered and tried all the suggestions here, and I’m still not able to get the date initialized to ‘now’. I’ve scrutinized all the various settings and connections. I am going to try to build a new app with only a date field, and build it up from there, and see what I learn; but any clarity to help me solve this problem ASAP would be greatly appreciated. I am a very advanced embedded software engineer, but I’m actually quite new to all the object-oriented app stuff. I’m really quite pleased with the whole Xcode/Cocoa/Objective-C toolset, but I admit I need some help.
I though I should add some more explanation of what I’ve tried and oberved. It seemed to me that I should be focusing on the “- (id)newObject” method in CarArrayController. First of all, the sample code from the website (in the Cocoa-4th.zip file) works correctly; so I added the line “NSLog(@“now = %@”, now);” to CarArrayController.m right after “NSDate *now = [NSDate date];” in the sample code, and it ran corretly, printing the current date in the debug area (console). So the I added the same line of code to my own CarArrayController.m, AND IT DID NOT PRINT. So, apparently, newObject is not being called in my code, but it IS in the sample code. I double-chacked all my references and connections. This made me suspicious of the sample code, thinking that the newObj is not being retained (because it is locally instantiated). Now, I have ARC set up correctly (I assume), which leads me to believe that the reference count is nonzero; therefore the local instanciation should not be garbage-collected. But maybe I’m wrong, and it is being garbale collected (or, in the normal C scoping way, is being popped off the stack as soon as the method returns). If it is behaving the way I am used to regarding C local instantiation, that would pop the instance, and the returned reference to newObj would be a null pointer. This might explain it. But then, why does his sample code work??? Anyway…I’m dumbfounded. Maybe this explanation will clue you into something that you could suggest. Thank you in advance.
I found my problem. First of all, as mmagiana said earlier, indeed you must apply the Cars binding to the Date Picker Cell, not the Textual Date Picker With Stepper (it seems you have to click again right on top of the date text). So after hours of scrutiny, I finally noticed a slight difference between my XCode and figure 11.13 in my book. I hadn’t checked one of the “Conditionally Sets …” boxes (I think it was the first one, “Conditionally Sets Editable”). The checkboxes are a little different in my version of Xcode compared to the book, so I must have missed it. Now my code is calling newObject in CarArrayController.m correctly, and the date is being set to today correctly! I hope this is helpful for somebody.
Thanks riceboy. Your fix worked for me. Some things, like changing class identities must not update right away when working in Interface Builder. I’m not sure what cleaning a project does, but it helped here.
I just wanted to get my two cents worth on this topic:
I mistakenly began another discussion regarding this same issue, and my solution was also rather bizzare (check my posts if you’re curious). I too had the problem of Xcode not marking my .xib file as dirty, although I never twigged on that possibly being the issue. Thanks for pointing this out!
It seems this is just an annoying bug we’ll have to be on the lookout for
Like many others I was initially stumped by this problem.
The solution is of course trivial.
When changing CODE Xcode will always autosave the changes before building the application.
This DOES NOT HAPPEN when changing IDENTITIES (and probably BINDINGS etc). It may look like you’ve set the arrayController’s identity to CarArrayController but as far as Xcode is concerned it still thinks its NSArrayController!
The book, at the foot of page 190, would have saved some of us a lot of anguish by stating: “SAVE then Build …”
Perhaps the authors were just teaching us a lesson. Always save before building.
[quote=“adlibber”]Like many others I was initially stumped by this problem.
The solution is of course trivial.
The book, at the foot of page 190, would have saved some of us a lot of anguish by stating: "SAVE then Build …"
Perhaps the authors were just teaching us a lesson. Always save before building.[/quote]
That’s it, just save the nib. Thanx.
One final note.
After setting the Cars array controller to the new CarArrayController class
1 - Clean the project
2 - Save the project
3- Build and run
Just saving it didn’t work for me. Xcode 5
and thanks to those who figured this out before me.