dateByAddingYears, Tiger & Leopard, and losing my mind

  • 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
  • OK, the problem ultimately is your use of NSCalendarDate.

    Core Data only natively supports NSDate. You can quite happily call
    setValue:forKey: with an NSCalendarDate, but whenever, retrieving
    that date from the managed object, you can no longer assume it is an
    NSCalendarDate; only that it is an NSDate.

    Thus, what is happening is you are calling the NSCalendarDate method -
    dateByAddingYears:months:days:hours:minutes:seconds: upon a plain
    NSDate which does not recognise such a method. Instead, your best bet
    is to use NSDate in combination with NSCalendar rather than
    NSCalendarDate.

    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
  • 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
previous month january 2008 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today