Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

macOS A bug in NSNumberFormatter ?

P

phjo

macrumors regular
Original poster
Jan 8, 2008
149
1
Or something I didn't understand with cocoa bindings...

I am doing some Hillegass exercices, while adapting things here and there for xcode 3, which adds some spice to it...

I am encountering a weird thing with the RaiseMan application (end of chapter 6)

So I sort of followed Aaron Hillegass instructions (just replacing standard accessors with properties, and of course creating new classes in xcode rather than subclassing from ib...) to do this introduction to cocoa bindings, but the NSNumberFormatter is not working as I think it should...

The <<Expected Raise>> value is initialized to 5% when a new entry is done, and everything looks fine and acts fine (creation, deletion, sorting) until I change one <<expected raise>> pourcentage to 1 % and blam, every other purcentage is multiplied by 100... And creation of new entries display now 500%...

If the formatter is configured in IB to use a different multiplier than 1 (which I chose by default) the same weird thing happens : multiplier is subsequently multiplied by 100 when I try to change one purcentage to 1%...

I am a bit surprised...

phjo

P.S. : By playing with cocoa bindings in the inspector, I've had IB crash a few times on me... It seems very easy to obtain the message I paste :
-----------------------------
Assertion Failure

Interface Builder encountered an internal logic error. Choose "Continue" to continue running Interface Builder in an inconsistent state. Choose "Crash" to halt Interface Builder and file a bug with Crash Reporter. Choosing "Crash" will result in the loss of all unsaved data.
-------------------------------------
Note that I did file a bug with Crash Reporter, but as IB 3 seems many months old already, I would suppose Apple received millions of such bug reports already...
 
Yeah, it could make sense to display a float with value of 1 as 100%, or 5 as 500% but that's not the point...

If I choose to do that, a new entry displays 500% which is to be expected with the initializer setting 5 for value, and there is then no error.

Until I change one value to 1% : all other values get then multiplied by 100, and new entries now are displayed as 50 000% and that is of course inconsistent.

phjo
 
OK, I did investigate a bit more, and it is a strange one !

Suppose you add a NSNumberFormatter, and choose to use percent, build and run it : no problem.

Second (or third !) time you build and run it : the bug appears...

Remove the NSNumberFormatter and add it again, no problem for the first build but the bug returns at second or third building !

I could reproduce the bug with or without cocoa bindings (see challenge 6.2 of the Hillegaas book...)

phjo
 
What kind of NIB file format are you are using? XIB, NIB 3.x or NIB 2.x? The reason I ask is XIBs are known to have some incompatibilities. You could also build your NSNumberFormatter in code and see if the bug is reproducible there as well.
 
kainjow said:
What kind of NIB file format are you are using? XIB, NIB 3.x or NIB 2.x? The reason I ask is XIBs are known to have some incompatibilities. You could also build your NSNumberFormatter in code and see if the bug is reproducible there as well.
Click to expand...

How do I tell ?

All I can say is that the project with which I encountered the problem first was Xcode 3+IB 3 from the beginning to the end...

I tried with importing a project done with Xcode 2.4 (with no bindings) and changing the NSNumberFormatter to use the buggy one (10.4+) : same bug.

phjo
 
Thats funny, I was just working on that chapter last night as well. I had difficulty the setNilValueForKey: method until I switched the IB NSNumberFormatter to 10.0+ compatibility. The code would compile (under 10.4); however, when I tested entering nil (nothing) into the percentage of raise column, I'd get an exception thrown. I believe this is due to how 10.4 upgraded NSNumberFormatter.
 
LOL, I was working on this chapter on Monday and had the same problem with all the numbers displaying as multiplied when one is edited (IB3 on Leopard).

I was monkeying around with the different settings a lot, trying to figure out which ones would work correctly (IB3 is much different than the screenshots from the book). I sort of got a feel for it, but I had to delete my original formatter and start with a fresh one to set the options the way I wanted--I could not restore my original formatter to the correct state (along the way, certain text boxes got disabled and I couldn't get them re-enabled)

I thought my problem had to do with how I had set the multiplier or factor (I'm not sure what it was labeled).

But the problem didn't persist for me. Once I replaced my messed up formatter with a new one and just set one or two things (sorry, I don't remember exactly what), the problem went away for good.

IB3's UI for number formatters might be buggy, but I definitely don't know enough about them to be sure about that. It's definitely confusing, but if I understood number formatters, it might make more sense. But hey, I'm only on chapter 7. One thing at a time!
 
Eraserhead said:
Cool, now of course you can't tell us what's happening with it :p.
Click to expand...

Can't ?

I am not sure I get what you mean there...

But if anything comes out of it, I'll post about it there. Bug state is now <<open>>, and I would not be surprised to see it changed as <<duplicate>> soon...

phjo
 
phjo said:
Can't ?

I am not sure I get what you mean there...

But if anything comes out of it, I'll post about it there. Bug state is now <<open>>, and I would not be surprised to see it changed as <<duplicate>> soon...

phjo
Click to expand...

I think he is refering to an NDA or something similar. Did you have to click on an agreement before submitting?
 
Cromulent said:
I think he is refering to an NDA or something similar. Did you have to click on an agreement before submitting?
Click to expand...

I don't think I did, or it just means I didn't read it !

But I wouldn't see the point anyway... I am the one providing the information, not Apple !

phjo
 
I narrowed it down a little. The problem has to do with using the "Grouping Separator" with the Percent style. Since "Grouping Separator" is selected by default when you choose the Percent style, it's pretty easy to trigger the bug.

The Multiplier doesn't seem to have anything to do with it. I tried it with 100 (the default) and 1 (needed for the RaiseMan app).

I tried the same grouping options with a few other styles (none and decimal), and there were no problems.

I don't know if IB3 is the problem, or if the bug is actually in NSNumberFormatter.
 
Well, I just tried disabling the grouping separator... The bug is still there for me.

phjo
 
Before finding this thread, I posted this to the cocoa-dev list. I managed to reproduce the problem outside of IB entirely, and found that one way to trigger the issue was to attempt to translate an invalid string value to a number. This typically happens during the process of modifying a table cell when running the program.

Not that we can do much about it. Any status on the bug, from the submitter?
 
No change in the status of the bug, which has been marked open since february... What is the most surprising is that it has not been marked duplicate as I am pretty sure it is not the only bug report about this, and certainly not the first...

I had a look at the third edition of Aaron Hillegass book... It explicitely asks for 10.0 style number formatter (which is not the IB default)...

phjo
 
phjo said:
No change in the status of the bug, which has been marked open since february... What is the most surprising is that it has not been marked duplicate as I am pretty sure it is not the only bug report about this, and certainly not the first...
Click to expand...

Any news on this bug? It still seems to exist in 10.5.7.

A work-around is to subclass NSNumberFormatter, override getObjectValue:forString:range:error:. Call super's implementation, and if the call fails, immediately call [self setNumberStyle:NSNumberFormatterPercentStyle] to reset whatever it is doing wrong when an improperly formatted string is passed.
 
Bakerman said:
Any news on this bug? It still seems to exist in 10.5.7.

A work-around is to subclass NSNumberFormatter, override getObjectValue:forString:range:error:. Call super's implementation, and if the call fails, immediately call [self setNumberStyle:NSNumberFormatterPercentStyle] to reset whatever it is doing wrong when an improperly formatted string is passed.
Click to expand...

Does someone have the bug ID?
 
Bug ID was 5756666, but I just checked today, it looks like it now has been closed... (Never received any update as regards the bug report, nor could I read any explanation as to why the bug got closed...)

phjo
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back