Re: Word 2004 VBA -> Applescript
- From: David-Artur Daix <daix@xxxxxxxxxxxxxxxx>
- Date: Fri, 01 Sep 2006 17:37:00 +0200
On 31/08/06 22:57, in article C11C9B64.DCCB1%berkowit@xxxxxxxxxxxxxxxx,
"Paul Berkowitz" <berkowit@xxxxxxxxxxxxxxxx> wrote:
It's annoying, since as far as I can tell you must have one compiled script
per subroutine, even for something as simple as 'save as active document
file name docName'.
That sounds like a reason in itself for trying out AppleScript Studio. You
can put everything in one script file if you like, although it is
recommended that you use an MVC (Model-View-Controller) structure for long
scripts and bugger projects. You can put your UI event-driven handlers in
the main script file and call out to "action" handlers in another script
file, for example. Or not. It's up0 to you. The full panoply of AppleScript
script objects and handlers (subroutines) are available to you as you like.
That's true, but that would mean rewriting _everything_ in AS or Obj-C.
Right now, I already have working code written in REAlbasic and the
FileMaker Pro database that I have created to produce the VBA code used in
the "transcoders" (huge arrays storing the characters to find and their
replacements) can be easily reconfigured to produce RB code instead. It
would be a much bigger effort to rewrite everything in AS or Obj-C. I may
have to if there are big performance issues when using RB, but if the only
drawback is having to create a few 'on run' scripts instead of one large
script, so be it. Right now I can limit the use of AS to just 5 or 6
subroutines, from tiny to small (my find & replace subroutine is the largest
of the bunch), when only Word itself can do the work.
BTW, about having to use individual files for each subroutine, that's just
par for the course when dealing with RB. In that environment _every_
method/function stands on its own. Each one of my VB transcoder module will
typically contain between ten and fifteen functions depending on the
different "translations" it has to deal with: when moved to RB, that module
becomes fifteen different methods and is all broken up.
The truth is, despite the difficulty of working with VBA on the Mac, I
actually really enjoyed programming using that language. REALbasic is quite
similar, but not quite as elegant IMO.
And I think I prefer both to AS.
But as always there is no accounting for taste. And in the end I'll use
whatever works.
We don't know at this point whether RealBasic's hooks into OLE will just
work "as is" on Intel Macs, or if RB will have to do a conversion similar to
what MS has declined to do for VBA. The reason why AppleScript just works
"as is" is because Apple has built the low-level changes into AppleScript
itself (and built the application conversion into Xcode's "Universal Binary"
checkbox). But Apple knew about the Intel changes for years and could plan
ahead.
I've posted messages on the REALbasic forums asking whether the Office
Automation features will still work in the next version of Office when VBA
is gone: I haven't received any answer. But I really doubt it.
In fact, with VBA gone, will OLE still be used in Office? Maybe AppleScript
will become the only model used in the next version for interapp
communication: wouldn't that make sense?
Yes. When you read the Neuburg book, you'll learn that it's a lot more
efficient to write:
set end of StoryRangeList to MainTextStoryRange
rather than
copy MainTextStoryRange to the end of StoryRangeListRef
but otherwise, yes, that will be fine. ('set end' doesn't have to keep
copying the entire list over and over internally.) Then you can operate on
the list in a repeat loop.
Thanks for the tip. I've ordered Neuburg's book and I'll read it carefully
as I prepare to make the move from VBA to AS.
Once it's working properly doing
repeat while next story range of storyRange is not missing value
my ProcessStoryRange(storyRange)
end repeat
will work just fine.
Great: I'll keep those lines in store for next year.
Once again, this is an enumeration (of '[background pattern] color index'
type). Naturally you can't the color index of a font to a string. Yes,
that's as good a way as any, but you'd need a subroutine that iterated
(if/else if) through all 18 color indices. Here's another way:
Actually I just need two cases: default is "auto" and then, once all the
replacements stored in the arrays are done, I call the CharConverter
function/method/script _once_ with the parameter "red" to color in red all
the characters that couldn't be transcoded at all (because they simply do
not exist in the target encoding). So a simple 'if... else' should do fine
and work fast.
Thanks again for your help.
Best wishes,
--
David-Artur Daix
Centre d'Études Anciennes
Département des Sciences de l'Antiquité
École Normale Supérieure
45 rue d'Ulm, 75230 Paris Cedex 05
<mailto:daix _AT_ ens _DOT_ fr>
<http://www.antiquite.ens.fr/index.html>
<http://www.greektranscoder.org>
.
- Follow-Ups:
- Re: Word 2004 VBA -> Applescript
- From: Paul Berkowitz
- Re: Word 2004 VBA -> Applescript
- References:
- Re: Word 2004 VBA -> Applescript
- From: Paul Berkowitz
- Re: Word 2004 VBA -> Applescript
- Prev by Date: Re: Continuing table titles
- Next by Date: can't adjust or resize toolbar
- Previous by thread: Re: Word 2004 VBA -> Applescript
- Next by thread: Re: Word 2004 VBA -> Applescript
- Index(es):
Relevant Pages
|
