numer as text -> wrong format

Scripting Forums AppleScript | Mac OS X
#1

hello, I am trying to write the size of a file (in bytes) to a textfile

the number comes out in scientific format, instead as one long integer

the following example code shows the problem:

on run
	set lnumber to 34342343233
	display dialog lnumber
	display dialog (lnumber as text)
end run

if you run this script, the first dialog displays “34342343233”, whereas the second displays “3.4342343233E+10”.

How do I control that formatting? I want to write “34342343233” to my file, not the scientifically formatted number

thanks
-frank

#2

Using AppleMods’ Number library:

-- auto-generated library loading code
property _Loader : run application "LoaderServer"

----------------------------------------------------------------------
-- DEPENDENCIES

property _Number : missing value

on __load__(loader)
	set _Number to loader's loadLib("Number")
end __load__

----------------------------------------------------------------------

-- main code

__load__(_Loader's makeLoader()) -- load libraries

_Number's numToText(34342343233, ".")
--> "34342343233"

If you’ve not used AppleMods’ libraries before, you’ll need to download and install AppleMods’ Loader system first. Run the Loader installer, then download and add the Number library to the ASLibraries folder. You can use the LoaderWizard applet to generate the library loading code to paste at the top of your script.

#3

Or there’s my numToStr() handler here in ScriptBuilders, which doesn’t need a loader.

set nstr to numToStr(3.4342343233E+10)
--> "34342343233.0"

Since 3.4342343233E+10 is an AppleScript ‘real’, the returned string will have “.0” on the end. If you don’t like this, it can easily be lost with:

if nstr ends with ".0" then set nstr to text 1 thru -3 of nstr

… or there’s a line near the end of the handler that you can disable.

#4

Strictly speaking neither does my example, since you can cut-n-paste the Number library’s numToText handler into your own code if you really want to. It’s just that cut-n-paste programming isn’t very good practice: it adds complexity and bloat to your own code which makes it harder to maintain and increases the risk of bugs sneaking in. The point of using libraries is to get all that gunk out of your way, which it does.

As for the bulky Loader boilerplate, blame AppleScript for not providing a built-in ‘import’ statement like any decent language would. You can auto-generate this code though so it’s generally a no-brainer, and the Loader applet itself isn’t required to run scripts, only to compile them. So while it’s not ideal it’s not too bad a trade-off either, when in return you get several hundred free, time-tested, ‘plug-n-play’ commands to play with.:wink:

BTW, if you want to load the libraries when the script is compiled, instead of when it’s run, change:

__load__(_Loader's makeLoader())

into:

property _ : __load__(_Loader's makeLoader())

Of course, this means you’ll need to recompile the script if you update the libraries later, but it can be useful for creating a compiled script that runs on other machines without having to install the libraries there as well.

HTH

#5

this is very good stuff
thank you both for your on-sthe-spot answers!!
cheers,
-frank