On Mar 6, 2015, at 5:34 PM, Shane Stanley < email@hidden> wrote:
On 7 Mar 2015, at 4:21 am, Alex Hall < email@hidden> wrote: It feels weird to say "current application's NSString…", but it works.
You can say 'current application's class "NSString"' if you'd prefer more typing practice :-)
The odd bit, for me, is having to say "current application's" at all. It feels like I'm asking Mail, or Script Editor, or Finder to give me an NSString, rather than making one from the actual Cocoa Foundations library. Hopefully I can cast this to a regular date object and format it how I want, check for how far away it is, and so on.
If, by regular date, you mean AppleScript date, then conversion is a bit messy. For some unknown reason, the two classes are not bridged. But it is a regular (NS)Date object. So you can do things like:
e's startDate()'s timeIntervalSinceNow()
And you can use date formatters to format it every which way.
*slaps forehead* See, I'm again forgetting that all of Cocoa (well, much of it) is open to me. can just call methods on the NSDate object directly, no casting necessary. The only tricky part will be converting back to text, so I can display or speak the information, but I can do much of this in ObjC, as you said. It seems like one could end up with the bulk of the logic and other internals all in ObjC, and only use AS for making the public-facing parts. I wish more than ever that Cocoa included easy ways of getting at ram/CPU information, so I could finally stop parsing Top or sysctl shell scripts, but that "Mach" library is a bear and I've found no alternatives. Anyway, thanks for all your help and sample code, I think I'm well on my way!
--
Have a great day, Alex Hall
|