Re: "Numeric overflow"?
Re: "Numeric overflow"?
- Subject: Re: "Numeric overflow"?
- From: Paul Berkowitz <email@hidden>
- Date: Tue, 13 Sep 2005 09:47:33 -0700
- Thread-topic: "Numeric overflow"?
On 9/13/05 7:54 AM, "Jon Pugh" <email@hidden> wrote:
> At 4:19 PM +0100 9/12/05, Mr Tea wrote:
>> Is your client juggling unfeasibly large numbers?
>
> More likely, is he dividing by unreasonably small numbers?
It turned out to be a sort of combined AppleScript/scripter (me) bug. Under
certain circumstances, an Excel cell might be empty. In Excel X, that got a
value of 0 (not 0.0. which is what you get if there's a numerical 0 in
there). But in Excel 2004, the value is (more reasonably) "", which is what
you always used to _set_ a cell empty - it now returns "" as well. in
addition, Excel text values are Unicode, so that's actually ("" as Unicode
text). In the meantime, my script, which was originally designed for Excel
X, tests
try
set cellValue to cellValue as real
on error
-- do stuff
end try
thinking that 0 would coerce to 0.0, and text would error. For example
"" as real
errors in the normal way. ("Cant make "" into type real.")
But
("" as Unicode text) as real
does not error normally, and is not trapped by the try block. Instead it
behaves rather freakishly, which I take to be some sort of AppleScript bug
that I'm trying to narrow down before reporting. (I also fixed my script.)
It behaves differently in different script editors and in script
applications, for starters.
In Script Editor 2.1 (Tiger), the script never finishes - it just sits there
forever spinning its wheels (still going aftyer 5 minutes! It doesn't even
arrive at an "AppleEvent timed out" - yet).
In Script Debugger 3.0.9, you get an error message:
Couldn't complete the last command because of a Mac OS error. Result
code: -2702"
which looks pretty definitive to me.
In a self-standing applet, on its own it just quits silently. If I add
("" as Unicode text) as real
display dialog (result as text)
you get what my user got: "The result of a numeric operation was too large".
If you click the Edit button with SD as default editor , it's the 'as text'
coercion that causes this latter error.
In Excel, certain operations with this command ends up with an absurdly
large negative number (scientific notation) in the cell.
So it looks like an AppleScript bug, at the root of things, where
("" as Unicode text) as real
doesn't error normally as it ought to, like
("a" as Unicode text) as real
does (Can't make "a" into type real).
("" as Unicode text) as integer
--> 0
correctly, but that's another matter.
--
Paul Berkowitz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden