Re: NSNumberFormatter 10.0+ style exception with zero
If I select the new-style NSNumberFormatter, I don't see a "Zero" field in Xcode/IB where I can enter that. Since it's working when I just create the formatter in code, I'll just keep doing that. What's really strange is that using the an almost identical project converted from Xcode 3.2 to Xcode 4, but where my text fields were NOT then dragged inside a new tab view, the same type of text fields hooked up to the same type of formatter works perfectly, and shows "N/A" when my text field values are 0. But in the project I'm working on, even if I delete the text fields and the formatter and drag&drop new ones, as long as they're inside the tab view, I get this behavior when the formatter is dragged&dropped in the xib, but no problems when the formatter is created in code. No time to track down why any more, though… got deadlines to meet! :-) Thanks, Howard On May 7, 2014, at 4:13 PM, Greg Parker wrote: > The implementation of old-style NSNumberFormatter has some sort of > compatibility code for old archive formats. It's possible that new versions > of Xcode don't write that old format correctly, or even try to do it at all. > > (The error occurs because the Zero field came back as an NSString instead of > an NSAttributedString, and the code wasn't expecting that.) > > Can you switch to the new-style NSNumberFormatter now? The new-style > NSNumberFormatter's zeroSymbol didn't work in 10.4 itself but should work in > later OS versions. > > > On May 7, 2014, at 2:51 PM, Gary L. Wade wrote: > >> There are occasional bugs when converting from earlier formats. What I do >> besides reporting the bug is to look at the underlying XML in the earlier >> version of the XIB and the later version and try to manually make the >> necessary changes using a text editor. I've sometimes had to quit Xcode, >> edit the XIB, lock the XIB so Xcode won't change it, and then relaunch >> Xcode. You may not have to go that far, but I wouldn't doubt that support >> for pre-10.4 number formatters to be lost in test for later-XIB formats. >> -- >> Gary L. Wade (Sent from my iPhone) >> http://www.garywade.com/ >> >>> On May 7, 2014, at 2:37 PM, Howard Moon wrote: >>> >>> Ok, this seems to be an IB issue. I've made my own NSNumberFormatter, set >>> its properties, and set it as the formatter for my text fields, all in >>> code, and that works perfectly. No idea why the same object created in >>> Xcode fails, but I'll do whatever it takes to make it work, I guess! >>> >>> Regards, >>> Howard >>> >>> On May 7, 2014, at 1:47 PM, Howard Moon wrote: Hm, it may be that something else is at play here. I did make ONE change when porting… I put my text fields inside a tab view. I wonder if maybe there's a problem accessing the number formatter from a control inside a tab view? All the connections *appear* to be there, and the call stack does show that it's accessing an NSNumberFormatter (and there's only on in my project). Need to run a test... Ok… I just tested the same code using the OLD xib, WITHOUT the tab view, and it works with no problems! So… does anyone know if simply adding a (two-tab) tab view and dragging existing objects on its pages causes any problems like this? Is there a connection I've overlooked that I need to make once the objects are inside that tab view? Thanks, -Howard > On May 7, 2014, at 9:34 AM, Howard Moon wrote: > > Hi, > > is the 10.0+ style of NSNumberFormatter no longer supported? I recently > moved from developing in Xcode3 under OS X 10.7 to Xcode 4 under OS X > 10.8, and from having a Base SDK of 10.6 to 10.7, and from a Deployment > Target of 10.5 to 10.6, and am now having problems with my xib-base > NSTextFields connected to an NSNumberFormatter. The formatter uses the > 10.0+ style, allowing me to set the "Zero" field, which I am setting to > the string N/A. This worked fine, even when running in 10.8 or 10.9, but > crashes now that I've compiled under these new conditions. > > Here is the call stack when the exception is thrown: > > 2014-05-07 08:32:15.225 Cubase 7.5[947:707] -[__NSCFString string]: > unrecognized selector sent to instance 0x1050188d0 > 2014-05-07 08:32:15.226 Cubase 7.5[947:707] NSInvalidArgumentException - > -[__NSCFString string]: unrecognized selector sent to instance 0x1050188d0 > 0 CoreFoundation 0x7fff92b32aee > __exceptionPreprocess + 174 > 1 libobjc.A.dylib 0x7fff8b8b13f0 > objc_exception_throw + 43 > 2 CoreFoundation 0x7fff92bc940a > -[NSObject(NSObject) doesNotRecognizeSelector:] + 186 > 3 CoreFoundation 0x7fff92b2102e > ___forwarding___ + 414 > 4 CoreFoundation
Re: NSNumberFormatter 10.0+ style exception with zero
The implementation of old-style NSNumberFormatter has some sort of compatibility code for old archive formats. It's possible that new versions of Xcode don't write that old format correctly, or even try to do it at all. (The error occurs because the Zero field came back as an NSString instead of an NSAttributedString, and the code wasn't expecting that.) Can you switch to the new-style NSNumberFormatter now? The new-style NSNumberFormatter's zeroSymbol didn't work in 10.4 itself but should work in later OS versions. On May 7, 2014, at 2:51 PM, Gary L. Wade wrote: > There are occasional bugs when converting from earlier formats. What I do > besides reporting the bug is to look at the underlying XML in the earlier > version of the XIB and the later version and try to manually make the > necessary changes using a text editor. I've sometimes had to quit Xcode, edit > the XIB, lock the XIB so Xcode won't change it, and then relaunch Xcode. You > may not have to go that far, but I wouldn't doubt that support for pre-10.4 > number formatters to be lost in test for later-XIB formats. > -- > Gary L. Wade (Sent from my iPhone) > http://www.garywade.com/ > >> On May 7, 2014, at 2:37 PM, Howard Moon wrote: >> >> Ok, this seems to be an IB issue. I've made my own NSNumberFormatter, set >> its properties, and set it as the formatter for my text fields, all in code, >> and that works perfectly. No idea why the same object created in Xcode >> fails, but I'll do whatever it takes to make it work, I guess! >> >> Regards, >> Howard >> >> >>> On May 7, 2014, at 1:47 PM, Howard Moon wrote: >>> >>> Hm, it may be that something else is at play here. I did make ONE change >>> when porting… I put my text fields inside a tab view. I wonder if maybe >>> there's a problem accessing the number formatter from a control inside a >>> tab view? All the connections *appear* to be there, and the call stack >>> does show that it's accessing an NSNumberFormatter (and there's only on in >>> my project). Need to run a test... >>> >>> Ok… I just tested the same code using the OLD xib, WITHOUT the tab view, >>> and it works with no problems! >>> >>> So… does anyone know if simply adding a (two-tab) tab view and dragging >>> existing objects on its pages causes any problems like this? Is there a >>> connection I've overlooked that I need to make once the objects are inside >>> that tab view? >>> >>> Thanks, >>> -Howard >>> On May 7, 2014, at 9:34 AM, Howard Moon wrote: Hi, is the 10.0+ style of NSNumberFormatter no longer supported? I recently moved from developing in Xcode3 under OS X 10.7 to Xcode 4 under OS X 10.8, and from having a Base SDK of 10.6 to 10.7, and from a Deployment Target of 10.5 to 10.6, and am now having problems with my xib-base NSTextFields connected to an NSNumberFormatter. The formatter uses the 10.0+ style, allowing me to set the "Zero" field, which I am setting to the string N/A. This worked fine, even when running in 10.8 or 10.9, but crashes now that I've compiled under these new conditions. Here is the call stack when the exception is thrown: 2014-05-07 08:32:15.225 Cubase 7.5[947:707] -[__NSCFString string]: unrecognized selector sent to instance 0x1050188d0 2014-05-07 08:32:15.226 Cubase 7.5[947:707] NSInvalidArgumentException - -[__NSCFString string]: unrecognized selector sent to instance 0x1050188d0 0 CoreFoundation 0x7fff92b32aee __exceptionPreprocess + 174 1 libobjc.A.dylib 0x7fff8b8b13f0 objc_exception_throw + 43 2 CoreFoundation 0x7fff92bc940a -[NSObject(NSObject) doesNotRecognizeSelector:] + 186 3 CoreFoundation 0x7fff92b2102e ___forwarding___ + 414 4 CoreFoundation 0x7fff92b20e18 _CF_forwarding_prep_0 + 232 5 Foundation 0x7fff93bc592b -[NSNumberFormatter(NSNumberFormatterCompatibility2) __oldnf_stringForObjectValue:] + 192 6 AppKit 0x7fff8bd2ba93 -[NSCell _stringForEditing] + 83 7 AppKit 0x7fff8bd35a32 -[NSCell _skipsSynchronizationForEditingTextView:] + 34 8 AppKit 0x7fff8bc5e43f -[NSCell setObjectValue:] + 296 9 AppKit 0x7fff8bc5e2fd -[NSTextFieldCell setObjectValue:] + 43 10 AppKit 0x7fff8be51cbd -[NSCell _setIntegerValue:] + 196 11 AppKit 0x7fff8be47f49 -[NSControl setIntValue:] + 138 ... I am simply calling setIntValue with a value of 0, which in previous builds would set the text field's text to "N/A". But now this e
Re: NSNumberFormatter 10.0+ style exception with zero
There are occasional bugs when converting from earlier formats. What I do besides reporting the bug is to look at the underlying XML in the earlier version of the XIB and the later version and try to manually make the necessary changes using a text editor. I've sometimes had to quit Xcode, edit the XIB, lock the XIB so Xcode won't change it, and then relaunch Xcode. You may not have to go that far, but I wouldn't doubt that support for pre-10.4 number formatters to be lost in test for later-XIB formats. -- Gary L. Wade (Sent from my iPhone) http://www.garywade.com/ > On May 7, 2014, at 2:37 PM, Howard Moon wrote: > > Ok, this seems to be an IB issue. I've made my own NSNumberFormatter, set > its properties, and set it as the formatter for my text fields, all in code, > and that works perfectly. No idea why the same object created in Xcode > fails, but I'll do whatever it takes to make it work, I guess! > > Regards, >Howard > > >> On May 7, 2014, at 1:47 PM, Howard Moon wrote: >> >> Hm, it may be that something else is at play here. I did make ONE change >> when porting… I put my text fields inside a tab view. I wonder if maybe >> there's a problem accessing the number formatter from a control inside a tab >> view? All the connections *appear* to be there, and the call stack does >> show that it's accessing an NSNumberFormatter (and there's only on in my >> project). Need to run a test... >> >> Ok… I just tested the same code using the OLD xib, WITHOUT the tab view, and >> it works with no problems! >> >> So… does anyone know if simply adding a (two-tab) tab view and dragging >> existing objects on its pages causes any problems like this? Is there a >> connection I've overlooked that I need to make once the objects are inside >> that tab view? >> >> Thanks, >>-Howard >> >>> On May 7, 2014, at 9:34 AM, Howard Moon wrote: >>> >>> Hi, >>> >>>is the 10.0+ style of NSNumberFormatter no longer supported? I recently >>> moved from developing in Xcode3 under OS X 10.7 to Xcode 4 under OS X 10.8, >>> and from having a Base SDK of 10.6 to 10.7, and from a Deployment Target of >>> 10.5 to 10.6, and am now having problems with my xib-base NSTextFields >>> connected to an NSNumberFormatter. The formatter uses the 10.0+ style, >>> allowing me to set the "Zero" field, which I am setting to the string N/A. >>> This worked fine, even when running in 10.8 or 10.9, but crashes now that >>> I've compiled under these new conditions. >>> >>> Here is the call stack when the exception is thrown: >>> >>> 2014-05-07 08:32:15.225 Cubase 7.5[947:707] -[__NSCFString string]: >>> unrecognized selector sent to instance 0x1050188d0 >>> 2014-05-07 08:32:15.226 Cubase 7.5[947:707] NSInvalidArgumentException - >>> -[__NSCFString string]: unrecognized selector sent to instance 0x1050188d0 >>> 0 CoreFoundation 0x7fff92b32aee >>> __exceptionPreprocess + 174 >>> 1 libobjc.A.dylib 0x7fff8b8b13f0 >>> objc_exception_throw + 43 >>> 2 CoreFoundation 0x7fff92bc940a >>> -[NSObject(NSObject) doesNotRecognizeSelector:] + 186 >>> 3 CoreFoundation 0x7fff92b2102e ___forwarding___ >>> + 414 >>> 4 CoreFoundation 0x7fff92b20e18 >>> _CF_forwarding_prep_0 + 232 >>> 5 Foundation 0x7fff93bc592b >>> -[NSNumberFormatter(NSNumberFormatterCompatibility2) >>> __oldnf_stringForObjectValue:] + 192 >>> 6 AppKit 0x7fff8bd2ba93 -[NSCell >>> _stringForEditing] + 83 >>> 7 AppKit 0x7fff8bd35a32 -[NSCell >>> _skipsSynchronizationForEditingTextView:] + 34 >>> 8 AppKit 0x7fff8bc5e43f -[NSCell >>> setObjectValue:] + 296 >>> 9 AppKit 0x7fff8bc5e2fd >>> -[NSTextFieldCell setObjectValue:] + 43 >>> 10 AppKit 0x7fff8be51cbd -[NSCell >>> _setIntegerValue:] + 196 >>> 11 AppKit 0x7fff8be47f49 -[NSControl >>> setIntValue:] + 138 >>> ... >>> >>> I am simply calling setIntValue with a value of 0, which in previous builds >>> would set the text field's text to "N/A". But now this exception is >>> thrown, and I don't know why or what to do about it. If the 10.0 style of >>> NSNumberFormatter is no longer supported, why is it still available in >>> Xcode 4, and why does it compile and run, up to the point I set its value >>> to 0? >>> >>> Thanks, >>>-Howard >>> >>> ___ >>> >>> 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/howard%40antarestech.c
Re: NSNumberFormatter 10.0+ style exception with zero
Ok, this seems to be an IB issue. I've made my own NSNumberFormatter, set its properties, and set it as the formatter for my text fields, all in code, and that works perfectly. No idea why the same object created in Xcode fails, but I'll do whatever it takes to make it work, I guess! Regards, Howard On May 7, 2014, at 1:47 PM, Howard Moon wrote: > Hm, it may be that something else is at play here. I did make ONE change > when porting… I put my text fields inside a tab view. I wonder if maybe > there's a problem accessing the number formatter from a control inside a tab > view? All the connections *appear* to be there, and the call stack does show > that it's accessing an NSNumberFormatter (and there's only on in my project). > Need to run a test... > > Ok… I just tested the same code using the OLD xib, WITHOUT the tab view, and > it works with no problems! > > So… does anyone know if simply adding a (two-tab) tab view and dragging > existing objects on its pages causes any problems like this? Is there a > connection I've overlooked that I need to make once the objects are inside > that tab view? > > Thanks, > -Howard > > On May 7, 2014, at 9:34 AM, Howard Moon wrote: > >> Hi, >> >> is the 10.0+ style of NSNumberFormatter no longer supported? I >> recently moved from developing in Xcode3 under OS X 10.7 to Xcode 4 under OS >> X 10.8, and from having a Base SDK of 10.6 to 10.7, and from a Deployment >> Target of 10.5 to 10.6, and am now having problems with my xib-base >> NSTextFields connected to an NSNumberFormatter. The formatter uses the >> 10.0+ style, allowing me to set the "Zero" field, which I am setting to the >> string N/A. This worked fine, even when running in 10.8 or 10.9, but >> crashes now that I've compiled under these new conditions. >> >> Here is the call stack when the exception is thrown: >> >> 2014-05-07 08:32:15.225 Cubase 7.5[947:707] -[__NSCFString string]: >> unrecognized selector sent to instance 0x1050188d0 >> 2014-05-07 08:32:15.226 Cubase 7.5[947:707] NSInvalidArgumentException - >> -[__NSCFString string]: unrecognized selector sent to instance 0x1050188d0 >> 0 CoreFoundation 0x7fff92b32aee >> __exceptionPreprocess + 174 >> 1 libobjc.A.dylib 0x7fff8b8b13f0 >> objc_exception_throw + 43 >> 2 CoreFoundation 0x7fff92bc940a >> -[NSObject(NSObject) doesNotRecognizeSelector:] + 186 >> 3 CoreFoundation 0x7fff92b2102e ___forwarding___ >> + 414 >> 4 CoreFoundation 0x7fff92b20e18 >> _CF_forwarding_prep_0 + 232 >> 5 Foundation 0x7fff93bc592b >> -[NSNumberFormatter(NSNumberFormatterCompatibility2) >> __oldnf_stringForObjectValue:] + 192 >> 6 AppKit 0x7fff8bd2ba93 -[NSCell >> _stringForEditing] + 83 >> 7 AppKit 0x7fff8bd35a32 -[NSCell >> _skipsSynchronizationForEditingTextView:] + 34 >> 8 AppKit 0x7fff8bc5e43f -[NSCell >> setObjectValue:] + 296 >> 9 AppKit 0x7fff8bc5e2fd -[NSTextFieldCell >> setObjectValue:] + 43 >> 10 AppKit 0x7fff8be51cbd -[NSCell >> _setIntegerValue:] + 196 >> 11 AppKit 0x7fff8be47f49 -[NSControl >> setIntValue:] + 138 >> ... >> >> I am simply calling setIntValue with a value of 0, which in previous builds >> would set the text field's text to "N/A". But now this exception is thrown, >> and I don't know why or what to do about it. If the 10.0 style of >> NSNumberFormatter is no longer supported, why is it still available in Xcode >> 4, and why does it compile and run, up to the point I set its value to 0? >> >> Thanks, >> -Howard >> >> ___ >> >> 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/howard%40antarestech.com >> >> This email sent to how...@antarestech.com > > > ___ > > 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/howard%40antarestech.com > > This email sent to how...@antarestech.com ___ 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
Re: NSNumberFormatter 10.0+ style exception with zero
Hm, it may be that something else is at play here. I did make ONE change when porting… I put my text fields inside a tab view. I wonder if maybe there's a problem accessing the number formatter from a control inside a tab view? All the connections *appear* to be there, and the call stack does show that it's accessing an NSNumberFormatter (and there's only on in my project). Need to run a test... Ok… I just tested the same code using the OLD xib, WITHOUT the tab view, and it works with no problems! So… does anyone know if simply adding a (two-tab) tab view and dragging existing objects on its pages causes any problems like this? Is there a connection I've overlooked that I need to make once the objects are inside that tab view? Thanks, -Howard On May 7, 2014, at 9:34 AM, Howard Moon wrote: > Hi, > > is the 10.0+ style of NSNumberFormatter no longer supported? I > recently moved from developing in Xcode3 under OS X 10.7 to Xcode 4 under OS > X 10.8, and from having a Base SDK of 10.6 to 10.7, and from a Deployment > Target of 10.5 to 10.6, and am now having problems with my xib-base > NSTextFields connected to an NSNumberFormatter. The formatter uses the 10.0+ > style, allowing me to set the "Zero" field, which I am setting to the string > N/A. This worked fine, even when running in 10.8 or 10.9, but crashes now > that I've compiled under these new conditions. > > Here is the call stack when the exception is thrown: > > 2014-05-07 08:32:15.225 Cubase 7.5[947:707] -[__NSCFString string]: > unrecognized selector sent to instance 0x1050188d0 > 2014-05-07 08:32:15.226 Cubase 7.5[947:707] NSInvalidArgumentException - > -[__NSCFString string]: unrecognized selector sent to instance 0x1050188d0 > 0 CoreFoundation 0x7fff92b32aee > __exceptionPreprocess + 174 > 1 libobjc.A.dylib 0x7fff8b8b13f0 > objc_exception_throw + 43 > 2 CoreFoundation 0x7fff92bc940a > -[NSObject(NSObject) doesNotRecognizeSelector:] + 186 > 3 CoreFoundation 0x7fff92b2102e ___forwarding___ + > 414 > 4 CoreFoundation 0x7fff92b20e18 > _CF_forwarding_prep_0 + 232 > 5 Foundation 0x7fff93bc592b > -[NSNumberFormatter(NSNumberFormatterCompatibility2) > __oldnf_stringForObjectValue:] + 192 > 6 AppKit 0x7fff8bd2ba93 -[NSCell > _stringForEditing] + 83 > 7 AppKit 0x7fff8bd35a32 -[NSCell > _skipsSynchronizationForEditingTextView:] + 34 > 8 AppKit 0x7fff8bc5e43f -[NSCell > setObjectValue:] + 296 > 9 AppKit 0x7fff8bc5e2fd -[NSTextFieldCell > setObjectValue:] + 43 > 10 AppKit 0x7fff8be51cbd -[NSCell > _setIntegerValue:] + 196 > 11 AppKit 0x7fff8be47f49 -[NSControl > setIntValue:] + 138 > ... > > I am simply calling setIntValue with a value of 0, which in previous builds > would set the text field's text to "N/A". But now this exception is thrown, > and I don't know why or what to do about it. If the 10.0 style of > NSNumberFormatter is no longer supported, why is it still available in Xcode > 4, and why does it compile and run, up to the point I set its value to 0? > > Thanks, > -Howard > > ___ > > 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/howard%40antarestech.com > > This email sent to how...@antarestech.com ___ 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
