Yvan, for file sizes there’s even a more convenient formatter
on formatnumber:theNumber
set theResult to current application's NSByteCountFormatter's stringFromByteCount:theNumber countStyle:(current application's NSByteCountFormatterCountStyleFile)
return theResult as text
end formatnumber:
Hey chaps.
If the attribute’s dictionary’s coerced to record, would the scripting bridge automatically take care of the integer type(s)?
use framework "Foundation"
set fileManager to current application's NSFileManager's defaultManager()
set attributes to fileManager's attributesOfFileSystemForPath:"/" |error|:(missing value)
-- Coerce the dictionary to record and read the free byte figure from that.
set freeBytes to (attributes as record)'s NSFileSystemFreeSize
set freeGigaBytes to (freeBytes / 1.0E+7 as integer) / 100
Or is it better to be explicit in ASObjC?
Good catch, Nigel.
Yes, that’s right indeed. The different types of NSNumber are bridged correctly to the appropriate AppleScript types.
I updated the code above again.
Thanks but I deliberately choose the Shane’s handler to show to interested users how to display a large number with all digits (not the scientific format).
In fact, using this handler there is no need to explicitly define a format.
use framework "Foundation"
set fileManager to current application's NSFileManager's defaultManager()
set attributes to fileManager's attributesOfFileSystemForPath:"/" |error|:(missing value)
set freeBytes to (attributes's objectForKey:(current application's NSFileSystemFreeSize))
set freeBytesYK to my formatnumber:freeBytes
--> "277 390 725 120"
on formatnumber:theNumber
set theResult to current application's NSNumberFormatter's localizedStringFromNumber:theNumber numberStyle:(current application's NSNumberFormatterDecimalStyle)
return theResult as text
end formatnumber:
Yvan KOENIG running El Capitan 10.11.5 in French (VALLAURIS, France) lundi 30 mai 2016 18:57:11
It’s indeed better to use higher level Cocoa classes than basic C-types. NSNumber objects are called by it’s instance methods and are converted (implicitly by NSNumber’s instance methods) to the right type before copied into an AppleScript number. But if someone needs an C-type value it’s then better to use integer types that are the same between different bit-modes. integerValue() is not specifically an issue to AppleScriptObjC but Objective-C/Cocoa in general since 64-bit support.
After testing with integerValue() and running SE in 32-bit mode I get the same results as with system events. To complete StefanK’s question, it seems that “System Event” is wrongly typecasting a 64-bit integer value into an 32-bit integer value even when running in 64-bit mode. If this problem still occurs on El Capitan it should be reported to the AppleScript engineers as a bug, but I don’t have 10.11.
I just noticed that size in System Events is defined as integer which is a fixed Int32 type. However the definition number can take types of variable length.
Hi Stefan and DJ.
Thanks for your replies. You’ve cleared that up for me.
Sorry about the accidental grocer’s apostrophe. :rolleyes:
[OT] In German there is a term “Freudscher Versprecher” (google says Freudian slip in english ??) that means a mistake because of a mental “misassociation”. In this case AppleScriptObjC with its apostrophic syntax.
That must have been it. 
In the case of integer values that could be outside AS’s integer range, quite the contrary.
use framework "Foundation"
set x to 2 ^ 32
set aNum to current application's NSNumber's numberWithInteger:x
aNum as integer --> error
set aNum to current application's NSArray's arrayWithObject:x
item 1 of (aNum as list) --> 4.294967296E+9
There’s also an issue with doubles losing precision when coerced to reals under 10.9; again, letting the bridge do the conversion is the solution.
But there’s no reason to convert to a record, as you’re passing the value to a Cocoa method. You can just use the NSNumber as returned directly.