Re: dateByAddingYears, Tiger & Leopard, and losing my mind
Re: dateByAddingYears, Tiger & Leopard, and losing my mind
- Subject: Re: dateByAddingYears, Tiger & Leopard, and losing my mind
- From: Mike Abdullah <email@hidden>
- Date: Tue, 1 Jan 2008 22:45:52 +0000
Also, I forgot to add that that there is no need for the -
willAccessValueForKey: and -didAccessValueForKey: calls in your
posted sample code.
Mike.
On 1 Jan 2008, at 22:32, Michael LaMorte wrote:
New Year's greetings to all,
I'm a relative Cocoa n00b, (came over from AppleScript land) and
would appreciate any help (or handholding) I can get with this
problem. I've Googled, searched through my stack-o-books, hit
#macdev on IRC, and am still stumped. Hopefully someone here can
shed some light on my problem:
I have a relatively simple program that was working fine under
Tiger, but for some reason broke under Leopard. I can take the
compiled executable and copy it to a Tiger machine and it will work
fine, but under Leo it hangs at a certain point. (Read on for
clarification.)
It's a CoreData app with a simple schema, one of the data fields is
a Date. When creating a new record, I programmatically set the date
to the current date using the following:
[self willAccessValueForKey: @"theDate"];
[self setValue:[NSCalendarDate date] forKey: @"theDate"];
[self didAccessValueForKey: @"theDate"];
Stepping through with breakpoints and NSLogging shows me that this
works fine.
In the interface, I have the date displayed in an NSDatePicker with
stepper. (Generated by option-dragging the CoreData model into the
IB window and having IB generate the interface elements for me.) So
long as the user doesn't change the date, they can input other data
into other fields, create new records, etc. There's some custom
logic executed on the theDate that also works fine, again so long
as the user doesn't change the date with the interface.
The instant the user changes the date in the UI, and even if they
change the date back to the current date, the application becomes
unresponsive to input to any other field, and the debugger window
shows this:
*** -[__NSCFDate
dateByAddingYears:months:days:hours:minutes:seconds:]: unrecognized
selector sent to instance 0x1ce630
Any bit of custom logic that uses the dateByAddingYears method
invokes the error. At this point, the user can still change the
date in the UI, but for all other fields, menu items, and interface
elements, the app is unresponsive to user input, and the app must
be terminated. Stepping through and NSLogging shows that the new
date is reflected in CoreData properly, but any execution of
dateByAddingYears, anywhere in the application, throws the same error.
Taking out setting the date programmatically, the same thing
happens: setting (or changing) the date via the UI hangs the app.
All date variables are instances of NSCalendarDate, and I've
checked umpteen times for stupid things like misspellings.
The odd thing is that none of this happens under Tiger, even after
re-compiling in XCode 3... the executable can still be copied to a
Tiger system and run without error, but hangs up on any Leo system.
I'm at wit's end and have been trying to fix this problem on and
off for 2 months.... Help!
- Mike
---
Michael A. LaMorte
"In matters of style, swim with the current;
In matters of principle, stand like a rock"
-Thomas Jefferson
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
40mikeabdullah.net
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden