Hans Eklundh wrote:
I have iWork 9 installed in Leopard, and after upgrading to Snow Leopard, Numbers don't accept negative values, e.g. -141. They are defined as text and are aligned left in the cell, even if the cell is defined for numbers. Positive values are defined as numbers and aligned right.
All my statistics are wrong now. I don't where to find a sollution. Need to fix this asap.
I am unable to reproduce the described behavior.
C3 : =C*2
D2 : =B*C-126
D3 : =(C/B)-1
B10 : =SUM(B)
C10 : =SUM(C)
D10 : =SUM(D)
Yvan KOENIG (VALLAURIS, France) lundi 7 septembre 2009 14:02:54
Looking at the example in the link you sent, to my eyes the dashes indicating a negative value are different in length in the entered cells and the calculated cells. I suspect you are typing something like an en dash when entering the data. That will cause Numbers to think the entry is text. Which key are you pressing to enter a negative number?
In the sample file which I received, the Inspector displayed automatic for the cell format but in the Index.xml it was described as text.
I asked the Inspector to apply the format numbers and all behaved well.
Alas, the OP told me that on its machine, applying numbers changed nothing.
Given that I send him:
+Before trying to reinstall,+
+apply the often described tips.+
+Of course, quit Numbers.+
+(1) run Disk Utilities to repair permissions.+
+(2) move Numbers's preferences file+
+< boot Volume >:Users:< your account >:Library:Preferences:com.apple.iWork.Numbers.plist+
+to the desktop then try to open the doc in Numbers.+
+(3) try to open the doc in an other user account.+
+And let me know the results.+
Wait and see.
Yvan KOENIG (VALLAURIS, France) lundi 7 septembre 2009 19:16:53
Thomas Wright1 wrote:
Looking at the example in the link you sent, to my eyes the dashes indicating a negative value are different in length in the entered cells and the calculated cells.
Looks that way to me, too.
If I hold option and hit the minus sign, I get the long dash and the number is text. I do not yet have Snow Leopard so I can't comment on any effect it might have on this.
I am using the short - key on my laptop, or the - key on the numeric keyboard when using my Mac Pro. I enter negative values in exactly the same way I always had (been using Numbers since the first version). Changing the cell style from autmatic to numbers does not change the strange behaviour.
We have the same problem on four Macs running 10.6 in my office.
On Macs still running 10.5, Numbers works fine.
1. Running Disk Utility and respairng persmissions didn't change the behaviour
2. Trashing preferences didn't either
3. Logging in on my guest account made a differnce, my guests can type negative values, not me
I have been given the advice to create a new account and move all my files to that account. It is a work around, but not a reasonable sollution or explanation on this very odd bug.
I realize that the problem is tied to my user account. It worked fine in 10.5 using the same account, but not in 10.6. There should be a simpler sollution to this bug.
Would you be willing to do a test to see if it is the correct minus sign by checking what character code is returned by =CODE(LEFT(B2,1)) where your strange negative number is in B2. The correct minus sign should be 45.
What I find odd is that you have this problem on several Macs but I have not heard any other report of it here (yet). Could this be related to a third party application or something special/different you have on these Macs? Or maybe it is related to the language setting that you are using?
I got the file.
I repeat that the cell is described as formatted as a text one.
The problem is that on my machine I am able to reset the format to number but the OP states that on its machine it can't be done.
He wrote also that he may enter numerical entries on an other machine as well as on its own one but using an alternate user account.
This means that the problem is not with an item installed in the global part of the system (like the main applications folder).
It is necesseraly in one of the numerous files of the original account.
At this time, the powerfull maintenance tools like Onyx aren't compatible with 10.6 so the OP can't apply one of them.
Three soluces are available:
(1) give the machine as is to Apple so that Bugs Hunters may try to identify the wrongdoer
(2) spend a lot of time trying to identify the wrongdoer by himself with no guarantee of result.
(3) decide that knowing the true wrongdoer doesn't matter and transfer the datas from the odd account to a clean one.
Yvan KOENIG (VALLAURIS, France) mardi 8 septembre 2009 14:10:02
I just find it strange that the text version of the number and the number version of the number have different looking minus signs. But looking at the image again, it is the text version with the short minus (which looks correct for a hyphen-minus) and the number version with the long minus (which looks like a different kind of hyphen).
Your first and last solutions seem reasonable. My concern is that this problem may reappear if it is the result of a third-party app or some setting that will get installed/set later in the new user account. Of course, it might be easier to nail down then. But I would be highly annoyed to have to recreate a user account.
I understand what you are saying, and the easy solution might be to start a new account on the Macs with this problem.
What is amazingly odd that exactly the same error appears on the four Macs we upgraded to Snow Leopard, while Numbers runs normal on the Macs still running 10.5.
I'll bet that once we upgrade them, the same problem will appear on those Macs as well.
I may guarantee that the cell contains a standard minus symbol.
I entered in the Index.xml to see if something was odd.
All is perfect.
I can't imagine that the OP replaced deliberately a wrong char by a correct one before sending the file to my mailbox.
And I repeat,
(1) in the file which I received, the cell was really treated as a text one.
(2) on my machine, on the OP's alternate machine, on the OP's alternate user account, resetting the cell's status to numbers apply well.
So, if a third party component is the culprit, it would be easy to identify: it must be in one of the user account able to receive third party items which means
<userAccount>:Library:Address Book Plug-Ins
<userAccount>:Library:Contextual Menu Items
But from my point of view it would be more efficient to try to search a culprit in the
An efficient tip would be to compress every subfolder of this folder as a .zip file and trash the original file.
Reboot so that the account restarts without the caches.
If th account continue to fail, my idea was bad.
If it behaves well, the culprit was one of the caches.
unpack them one by one so you will get the wrongdoer.
Yvan KOENIG (VALLAURIS, France) mardi 8 septembre 2009 18:50:27