self.myTextField.stringValue = @"" fails

  • Hi,

    I have a text field that when I try to set it to a literal string fails:
    This is the code:
    self.myTextField.stringValue = @""; (It also fails if the literal string is not empty).

    This is the (partial) backtrace:
    2012-05-08 18:09:28.516 MyApp[18775:507] *** Assertion failure in -[NSTextFieldCell _objectValue:forString:errorDescription:], /SourceCache/AppKit/AppKit-1138.32/AppKit.subproj/NSCell.m:1564

    Catchpoint 7 (exception thrown).2012-05-08 18:09:31.742 MyApp[18775:507] Invalid parameter not satisfying: aString != nil
    2012-05-08 18:09:31.845 MyApp[18775:507] (
    0  CoreFoundation                      0x00007fff90d12fc6 __exceptionPreprocess + 198
    1  libobjc.A.dylib                    0x00007fff8c3f4d5e objc_exception_throw + 43
    2  CoreFoundation                      0x00007fff90d12dfa +[NSException raise:format:arguments:] + 106
    3  Foundation                          0x00007fff92db1743 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 169
    4  AppKit                              0x00007fff8a9495a5 -[NSCell _objectValue:forString:errorDescription:] + 160
    5  AppKit                              0x00007fff8a9494ff -[NSCell _objectValue:forString:] + 19
    6  AppKit                              0x00007fff8a949465 -[NSCell setStringValue:] + 41
    7  AppKit                              0x00007fff8aa4a5e8 -[NSControl setStringValue:] + 115

    However, when I set it like this…

    self.myTextField.stringValue = [NSString string];

    …it has no issues.

    Can anyone explain to me why the former doesn't work? I have many instances of setting a textfield with an empty literal string elsewhere in my code, and it doesn't cause problems. This particular textfield lives in a toolbar, but I assume that shouldn't matter.

    -Ant´ønio

    ----------------------------------------------------
    It is better to light a candle than to curse the darkness
    ----------------------------------------------------
  • Read the message...

    Catchpoint 7 (exception thrown).2012-05-08 18:09:31.742 MyApp[18775:507] Invalid parameter not satisfying: aString != nil
    On May 8, 2012, at 12:15 PM, Antonio Nunes wrote:

    > Catchpoint 7 (exception thrown).2012-05-08 18:09:31.742 MyApp[18775:507] Invalid parameter not satisfying: aString != nil

    @"" is the nil string and the compiler is smart enough to make the substitution.

    Charlie Dickman
    <3tothe4th...>
  • On May 8, 2012, at 9:28 AM, Charlie Dickman wrote:

    > @"" is the nil string and the compiler is smart enough to make the substitution.

    Um … pardon me, but WTF? There is no such thing as a “nil string” object. @“” is a perfectly valid NSString instance with a non-nil pointer. It just happens to contain zero characters. The compiler is absolutely not going to replace it with a nil pointer.

    I don’t know what the problem is in the OP’s code, but I wanted to reply ASAP to quash the idea of a “nil string” substitution.

    —Jens
  • There's definitely a nil being passed somewhere it shouldn't, I don't have any insights on that based on what was posted. However, I don't think @"" will be nil (at least it isn't in Xcode 4.3.2 for iOS 5.1):

    NSString* theString = @"";
    NSLog(@"%p", theString);

    prints

    2012-05-08 09:54:20.270 iSplit[1450:15503] 0x235f24

    Aaron

    On May 8, 2012, at 9:28 AM, Charlie Dickman wrote:

    > Read the message...
    >
    > Catchpoint 7 (exception thrown).2012-05-08 18:09:31.742 MyApp[18775:507] Invalid parameter not satisfying: aString != nil
    > On May 8, 2012, at 12:15 PM, Antonio Nunes wrote:
    >
    >> Catchpoint 7 (exception thrown).2012-05-08 18:09:31.742 MyApp[18775:507] Invalid parameter not satisfying: aString != nil
    >
    > @"" is the nil string and the compiler is smart enough to make the substitution.
    >
    > Charlie Dickman
    > <3tothe4th...>
    >
  • On May 8, 2012, at 9:15 AM, Antonio Nunes wrote:

    > I have a text field that when I try to set it to a literal string fails:
    > This is the code:
    > self.myTextField.stringValue = @""; (It also fails if the literal string is not empty).

    That is quite bizarre. So much so that I’m assuming that this isn’t the actual problem, that there’s a mixup about which line is raising the exception.

    > This is the (partial) backtrace:
    > 2012-05-08 18:09:28.516 MyApp[18775:507] *** Assertion failure in -[NSTextFieldCell _objectValue:forString:errorDescription:], /SourceCache/AppKit/AppKit-1138.32/AppKit.subproj/NSCell.m:1564
    >
    > Catchpoint 7 (exception thrown).2012-05-08 18:09:31.742 MyApp[18775:507] Invalid parameter not satisfying: aString != nil
    > 2012-05-08 18:09:31.845 MyApp[18775:507] (
    > 0  CoreFoundation                      0x00007fff90d12fc6 __exceptionPreprocess + 198
    > 1  libobjc.A.dylib                    0x00007fff8c3f4d5e objc_exception_throw + 43
    > 2  CoreFoundation                      0x00007fff90d12dfa +[NSException raise:format:arguments:] + 106
    > 3  Foundation                          0x00007fff92db1743 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 169
    > 4  AppKit                              0x00007fff8a9495a5 -[NSCell _objectValue:forString:errorDescription:] + 160
    > 5  AppKit                              0x00007fff8a9494ff -[NSCell _objectValue:forString:] + 19
    > 6  AppKit                              0x00007fff8a949465 -[NSCell setStringValue:] + 41
    > 7  AppKit                              0x00007fff8aa4a5e8 -[NSControl setStringValue:] + 115

    So, what’s line 8? Are you *certain* that it’s the line you quoted above, and not some other -setStringValue: call in your code?
    If you set a breakpoint on the line in question, and then step over the call, does the exception trigger?

    The only other explanation I can think of is that some previous bug in the code has messed up the predefined NSString instance that @“” points to. But that would be hard to do — IIRC, the compile-time-constant NSStrings are somewhat magical and don’t track refcounts, so you can’t over-release them.

    —Jens
  • On 8 May 2012, at 19:01, Jens Alfke wrote:

    > On May 8, 2012, at 9:15 AM, Antonio Nunes wrote:
    >
    >> I have a text field that when I try to set it to a literal string fails:
    >> This is the code:
    >> self.myTextField.stringValue = @""; (It also fails if the literal string is not empty).
    >
    > That is quite bizarre. So much so that I’m assuming that this isn’t the actual problem, that there’s a mixup about which line is raising the exception.

    I don't think so. I set a break point and then step over the line in question which immediately causes the assertion failure.

    >> This is the (partial) backtrace:
    >> 2012-05-08 18:09:28.516 MyApp[18775:507] *** Assertion failure in -[NSTextFieldCell _objectValue:forString:errorDescription:], /SourceCache/AppKit/AppKit-1138.32/AppKit.subproj/NSCell.m:1564
    >>
    >> Catchpoint 7 (exception thrown).2012-05-08 18:09:31.742 MyApp[18775:507] Invalid parameter not satisfying: aString != nil
    >> 2012-05-08 18:09:31.845 MyApp[18775:507] (
    >> 0  CoreFoundation                      0x00007fff90d12fc6 __exceptionPreprocess + 198
    >> 1  libobjc.A.dylib                    0x00007fff8c3f4d5e objc_exception_throw + 43
    >> 2  CoreFoundation                      0x00007fff90d12dfa +[NSException raise:format:arguments:] + 106
    >> 3  Foundation                          0x00007fff92db1743 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 169
    >> 4  AppKit                              0x00007fff8a9495a5 -[NSCell _objectValue:forString:errorDescription:] + 160
    >> 5  AppKit                              0x00007fff8a9494ff -[NSCell _objectValue:forString:] + 19
    >> 6  AppKit                              0x00007fff8a949465 -[NSCell setStringValue:] + 41
    >> 7  AppKit                              0x00007fff8aa4a5e8 -[NSControl setStringValue:] + 115
    >
    > So, what’s line 8? Are you *certain* that it’s the line you quoted above, and not some other -setStringValue: call in your code?
    > If you set a breakpoint on the line in question, and then step over the call, does the exception trigger?

    Yes. This is the surrounding code:

      if (self.toolbarPageNumberTextField.integerValue != self.pageListController.selectionIndex + 1) {
      if (self.toolbarPageNumberTextField.integerValue == NSNotFound) {
        self.toolbarPageNumberTextField.stringValue = @"";
      } else {
        NSUInteger idx = self.pageListController.selectionIndex;
        if ( idx != NSNotFound ) {
        self.toolbarPageNumberTextField.integerValue = idx + 1;
        } else {
        self.toolbarPageNumberTextField.stringValue = @"";
        }
      }
      }

    > The only other explanation I can think of is that some previous bug in the code has messed up the predefined NSString instance that @“” points to. But that would be hard to do — IIRC, the compile-time-constant NSStrings are somewhat magical and don’t track refcounts, so you can’t over-release them.

    I don't release @"" anywhere, so that is indeed very, very unlikely. Also, if I avoid the exception and assign @"" to a text field a bit later on in another piece of code, it works just fine. Could it be a compiler bug?

    -António

    ----------------------------------------------------
    It isn't so important to do great things,
    as to do what you do with great love.
    ----------------------------------------------------
  • On 08 May 2012, at 9:28 am, Charlie Dickman wrote:

    >> Catchpoint 7 (exception thrown).2012-05-08 18:09:31.742 MyApp[18775:507] Invalid parameter not satisfying: aString != nil
    >
    > @"" is the nil string and the compiler is smart enough to make the substitution.

    Certainly not true.  @"" is a zero-length string.  It is an NSString object.  It has an address.  It is most definitely not nil.

    -b

    --
    Ben Kennedy, chief magician
    Zygoat Creative Technical Services
    http://www.zygoat.ca
  • Rather than use:  self.myTextField.stringValue = @"";

    Couldn't you use:  self.myTextField.setStringValue = @"";  ?

    --
    Leandro Hoffman
  • Bizarre indeed. Out of curiosity, are you using ARC? Maybe the compiler is confusedly zeroing a non-weak pointer. I'm *really* grasping at straws, though.

    Are there any bindings on the text field? Again, I don't see why it would matter; just wondering.

    On May 8, 2012, at 1:13 PM, Antonio Nunes wrote:
    > I don't release @"" anywhere, so that is indeed very, very unlikely. Also, if I avoid the exception and assign @"" to a text field a bit later on in another piece of code, it works just fine.

    The same text field (toolbarPageNumberTextField), or a different one?

    --Andy
  • On 8 May 2012, at 21:46, Andy Lee wrote:

    > Bizarre indeed. Out of curiosity, are you using ARC? Maybe the compiler is confusedly zeroing a non-weak pointer. I'm *really* grasping at straws, though.

    No ARC. No garbage collection either.

    > Are there any bindings on the text field? Again, I don't see why it would matter; just wondering.

    No bindings.

    >> I don't release @"" anywhere, so that is indeed very, very unlikely. Also, if I avoid the exception and assign @"" to a text field a bit later on in another piece of code, it works just fine.
    >
    > The same text field (toolbarPageNumberTextField), or a different one?

    Another text field. I'm seeing different behaviour though between letting the code run naturally to the empty string assignment and manually moving the PC to the line in question. I'll take another look at it after a good night's sleep...

    -António

    -----------------------------------------
    Accepting others as they are
    brings a wonderful freedom
    to your own mind.

    --The Peace Formula
    -----------------------------------------
  • On May 8, 2012, at 1:35 PM, Antonio Nunes <devlists...> wrote:

    > On 8 May 2012, at 21:46, Andy Lee wrote:
    >
    >> Bizarre indeed. Out of curiosity, are you using ARC? Maybe the compiler is confusedly zeroing a non-weak pointer. I'm *really* grasping at straws, though.
    >
    > No ARC. No garbage collection either.
    >
    >> Are there any bindings on the text field? Again, I don't see why it would matter; just wondering.
    >
    > No bindings.
    >
    >>> I don't release @"" anywhere, so that is indeed very, very unlikely. Also, if I avoid the exception and assign @"" to a text field a bit later on in another piece of code, it works just fine.
    >>
    >> The same text field (toolbarPageNumberTextField), or a different one?
    >
    > Another text field. I'm seeing different behaviour though between letting the code run naturally to the empty string assignment and manually moving the PC to the line in question. I'll take another look at it after a good night's sleep...

    You may have a formatter on the cell, and it is returning nil.

    Also, you are mixing what you are using the text field for. In some cases you are treating it like an integer, and in others a string. I don't recommend using integerValue in your case; instead, convert that integer to a string (and vice-versa when you read the value via self.toolbarPageNumberTextField.integerValue). If you fix those things your problem will probably go away.

    --corbin
  • On 8 May 2012, at 23:10, Corbin Dunn wrote:

    >
    > On May 8, 2012, at 1:35 PM, Antonio Nunes <devlists...> wrote:
    >
    >> On 8 May 2012, at 21:46, Andy Lee wrote:
    >>
    >>> Bizarre indeed. Out of curiosity, are you using ARC? Maybe the compiler is confusedly zeroing a non-weak pointer. I'm *really* grasping at straws, though.
    >>
    >> No ARC. No garbage collection either.
    >>
    >>> Are there any bindings on the text field? Again, I don't see why it would matter; just wondering.
    >>
    >> No bindings.
    >>
    >>>> I don't release @"" anywhere, so that is indeed very, very unlikely. Also, if I avoid the exception and assign @"" to a text field a bit later on in another piece of code, it works just fine.
    >>>
    >>> The same text field (toolbarPageNumberTextField), or a different one?
    >>
    >> Another text field. I'm seeing different behaviour though between letting the code run naturally to the empty string assignment and manually moving the PC to the line in question. I'll take another look at it after a good night's sleep...
    >
    > You may have a formatter on the cell, and it is returning nil.
    >
    > Also, you are mixing what you are using the text field for. In some cases you are treating it like an integer, and in others a string. I don't recommend using integerValue in your case; instead, convert that integer to a string (and vice-versa when you read the value via self.toolbarPageNumberTextField.integerValue). If you fix those things your problem will probably go away.

    Thanks Corbin,

    Indeed, there is a number formatter on the cell, so probably that is causing the issue then. To make it possible to have an empty text field when there are no pages in the document I changed the symbol for 0:
    [self.toolbarPageNumberTextField.formatter setZeroSymbol:@""]; (I did not know this is possible, until a few minutes ago.)

    Then changed all instances of:
        self.toolbarPageNumberTextField.stringValue = @"";

    to
        self.toolbarPageNumberTextField.stringValue = @"0";

    Following your recommendation I also changed
        self.toolbarPageNumberTextField.integerValue = self.pageListController.selectionIndex + 1;
    to
        self.toolbarPageNumberTextField.stringValue = [NSString stringWithFormat:@"%d", self.pageListController.selectionIndex + 1];

    Why do you recommend against using integerValue? For me it would make more sense to always use integerValue, especially now that I can set the value to 0 to show an empty text field, since we're conceptually representing numbers here, not strings.

    -António

    -----------------------------------------------------------
    Don't believe everything you think
    -----------------------------------------------------------
  • On May 9, 2012, at 2:41 AM, Leandro Hoffman wrote:

    > Rather than use:  self.myTextField.stringValue = @"";
    >
    > Couldn't you use:  self.myTextField.setStringValue = @"";  ?
    >
    > --
    > Leandro Hoffman

    No. That's meaningless.

    self.myTextField.stringValue = @"";

    is just syntactic sugar for

    [ self.myTextField setStringValue:@"" ];

    is that what you meant? Doesn't matter which you write, you'll get the same actual call either way, it will call setStringValue:

    but xxx.setStringValue=@"" means nothing and wouldn't compile.
  • In my experience, setting a text field to the empty string will have it return nil when you access the string. I can't quite relate it to the code path you're following, but it may be a clue.

    — F

    On 8 May 2012, at 10:48 PM, Antonio Nunes wrote:

    > Why do you recommend against using integerValue? For me it would make more sense to always use integerValue, especially now that I can set the value to 0 to show an empty text field, since we're conceptually representing numbers here, not strings.
  • Sorry but that just doesn't make sense. The empty string and nil are just not the same thing. If you set a text field's text to the empty string, you will get an empty string, you will not get nil. The only way I can imagine this happening is if the text field is nil at the point you set the empty (or any other) string into it so you didn't really set anything at all.

    On May 9, 2012, at 11:18 PM, Fritz Anderson wrote:

    > In my experience, setting a text field to the empty string will have it return nil when you access the string. I can't quite relate it to the code path you're following, but it may be a clue.
    >
    > — F
    >
    > On 8 May 2012, at 10:48 PM, Antonio Nunes wrote:
    >
    >> Why do you recommend against using integerValue? For me it would make more sense to always use integerValue, especially now that I can set the value to 0 to show an empty text field, since we're conceptually representing numbers here, not strings.

  • On May 9, 2012, at 10:30 AM, Roland King wrote:

    > On May 9, 2012, at 11:18 PM, Fritz Anderson wrote:
    >
    >> In my experience, setting a text field to the empty string will have it return nil when you access the string. I can't quite relate it to the code path you're following, but it may be a clue.
    >
    > Sorry but that just doesn't make sense. The empty string and nil are just not the same thing. If you set a text field's text to the empty string, you will get an empty string, you will not get nil. The only way I can imagine this happening is if the text field is nil at the point you set the empty (or any other) string into it so you didn't really set anything at all.

    Well, there was a bad claim earlier in the thread about the empty string being a "nil string object", but Fritz isn't completely off-base here.  If you bind a text field's value to a string property, the string property will typically be assigned nil whenever the text field is empty.

    That's apparently not involved in the OP's situation, but he's not imagining it.

    Regards,
    Ken
  • On May 8, 2012, at 8:48 PM, Antonio Nunes <devlists...> wrote:

    > On 8 May 2012, at 23:10, Corbin Dunn wrote:
    >
    >>
    >> On May 8, 2012, at 1:35 PM, Antonio Nunes <devlists...> wrote:
    >>
    >>> On 8 May 2012, at 21:46, Andy Lee wrote:
    >>>
    >>>> Bizarre indeed. Out of curiosity, are you using ARC? Maybe the compiler is confusedly zeroing a non-weak pointer. I'm *really* grasping at straws, though.
    >>>
    >>> No ARC. No garbage collection either.
    >>>
    >>>> Are there any bindings on the text field? Again, I don't see why it would matter; just wondering.
    >>>
    >>> No bindings.
    >>>
    >>>>> I don't release @"" anywhere, so that is indeed very, very unlikely. Also, if I avoid the exception and assign @"" to a text field a bit later on in another piece of code, it works just fine.
    >>>>
    >>>> The same text field (toolbarPageNumberTextField), or a different one?
    >>>
    >>> Another text field. I'm seeing different behaviour though between letting the code run naturally to the empty string assignment and manually moving the PC to the line in question. I'll take another look at it after a good night's sleep...
    >>
    >> You may have a formatter on the cell, and it is returning nil.
    >>
    >> Also, you are mixing what you are using the text field for. In some cases you are treating it like an integer, and in others a string. I don't recommend using integerValue in your case; instead, convert that integer to a string (and vice-versa when you read the value via self.toolbarPageNumberTextField.integerValue). If you fix those things your problem will probably go away.
    >
    > Thanks Corbin,
    >
    > Indeed, there is a number formatter on the cell

    Okay-- then that is the problem; the formatter is failing to format "" to be a number, and giving 'nil' back when you call setStringValue.

    > , so probably that is causing the issue then. To make it possible to have an empty text field when there are no pages in the document I changed the symbol for 0:
    > [self.toolbarPageNumberTextField.formatter setZeroSymbol:@""]; (I did not know this is possible, until a few minutes ago.)

    >
    > Then changed all instances of:
    > self.toolbarPageNumberTextField.stringValue = @"";
    >
    > to
    > self.toolbarPageNumberTextField.stringValue = @"0";
    >

    Did that fix the problem?

    > Following your recommendation I also changed
    > self.toolbarPageNumberTextField.integerValue = self.pageListController.selectionIndex + 1;
    > to
    > self.toolbarPageNumberTextField.stringValue = [NSString stringWithFormat:@"%d", self.pageListController.selectionIndex + 1];
    >
    > Why do you recommend against using integerValue? For me it would make more sense to always use integerValue, especially now that I can set the value to 0 to show an empty text field, since we're conceptually representing numbers here, not strings.

    Well, it is just more consistent if you treat it all the same. Plus, when you read the integerValue, what NSCell doe is creates an NSScanner and scans the string (in the cell) for an integer and returns that value. This creates a scanner with your current locale...which may or may not be what you want (it probably is). When you call setIntegerValue it sets the objectValue of the cell to be an NSNumber. It really isn't an issue, but it just flip-flops the value type from a string to an integer back and forth.

    corbin

    >
    > -António
    >
    >
    >
    > -----------------------------------------------------------
    > Don't believe everything you think
    > -----------------------------------------------------------
    >
    >
    >
    >
  • On 9 May 2012, at 19:55, Corbin Dunn wrote:

    >> , so probably that is causing the issue then. To make it possible to have an empty text field when there are no pages in the document I changed the symbol for 0:
    >> [self.toolbarPageNumberTextField.formatter setZeroSymbol:@""]; (I did not know this is possible, until a few minutes ago.)
    >
    >>
    >> Then changed all instances of:
    >> self.toolbarPageNumberTextField.stringValue = @"";
    >>
    >> to
    >> self.toolbarPageNumberTextField.stringValue = @"0";
    >>
    >
    > Did that fix the problem?

    I think it did. Still need to confirm with the person who initially alerted me to the issue, but I can no longer make it crash.

    >> Following your recommendation I also changed
    >> self.toolbarPageNumberTextField.integerValue = self.pageListController.selectionIndex + 1;
    >> to
    >> self.toolbarPageNumberTextField.stringValue = [NSString stringWithFormat:@"%d", self.pageListController.selectionIndex + 1];
    >>
    >> Why do you recommend against using integerValue? For me it would make more sense to always use integerValue, especially now that I can set the value to 0 to show an empty text field, since we're conceptually representing numbers here, not strings.
    >
    > Well, it is just more consistent if you treat it all the same. Plus, when you read the integerValue, what NSCell doe is creates an NSScanner and scans the string (in the cell) for an integer and returns that value. This creates a scanner with your current locale...which may or may not be what you want (it probably is). When you call setIntegerValue it sets the objectValue of the cell to be an NSNumber. It really isn't an issue, but it just flip-flops the value type from a string to an integer back and forth.

    Thanks for explaining that so clearly Corbin.

    -António

    ----------------------------------------------------
    It is better to light a candle than to curse the darkness
    ----------------------------------------------------
previous month may 2012 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