Re: VBA to Applescript
Re: VBA to Applescript
- Subject: Re: VBA to Applescript
- From: has <email@hidden>
- Date: Fri, 15 Feb 2008 13:00:32 +0000
On 15 Feb 2008, at 07:32, Paul Berkowitz wrote:
I didn't quite describe the issue correctly. In AppleScript, as far
as I
know, you can
make new [element] at [(end of) class] with properties {record}
Are you saying that the sdef format allows a read-only element
access to the
class in question such that 'make new' is not permitted/errors?
I've never had occasion to test it myself, but I believe that's the
idea. In Carbon-based scripting implementations, all behaviour is
specified by the application's code and its dictionary exists for
documentation purposes only. Cocoa Scripting takes a more data-driven
approach, reducing the amount of code that needs to be written by
allowing many basic behaviours to be specified by its dictionary.
However, even if your scripting implementation doesn't use CS, there's
nothing magical in making an object's elements immutable - you just
don't write the code that allows users to modify them.
If so, that's interesting. Microsoft Excel is, of course, very far
from
being Cocoa Scripting - it's as Carbon as they come. And when its
AppleScript implementation was being re-done for Office 2004, the OS
was
still Jaguar (got to Panther just before 2004 release, but the
implementation started several years earlier). I don't know how
developed
the sdef format was at that time - I'm pretty sure it was nowhere
near the
finished article - Jaguar still used Script Editor 1.9. They were
working
with aete, not sdef.
The choice of aete or sdef wouldn't make any difference; like I say,
in Carbon apps the dictionary is purely for documentation purposes.
I don't think they'd redo it all now. Too bad, that looks like a
much better
way to hook into the VBA (actually, OLE) object model for these
Collections/classes. There are really a lot of them.
Alas, I'm still using Office X so couldn't comment on the pros and
cons of Office 2004/2008's scripting interface, which I believe is
quite a bit different.
has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden