Moving from Microsoft Office VBA to AppleScript:
MacTech's Guide to Making the Transition

Page Prev and Page Next buttons at bottom of the page.

April, 2007
Page 9

There is another situation where it is customary although not necessary to include on run: if you are making a "droplet" (a script application activated by dropping files or folders on it) with the obligatory on open handler and also want a separate procedure to engage if you double-click the droplet file: then you‘d put it in a 'run' handler.

Many – perhaps most – simple scripts have only the top level, with no extra subroutines (handlers). If you are converting a macro that has just the one Sub(), that‘s all you‘ll need. But what about more complex macros that call other Subs or Functions? It‘s virtually identical in AppleScript, except that you don‘t use the word "Sub" or "Function" at all: the parentheses after a name is what tells AppleScript you‘re calling a handler. (There is another way to call and name handlers without parentheses, called "labeled parameters", but almost nobody uses them.)

Thus, there‘s also no difference syntactically in AppleScript between what would be in VBA a Sub (that does some procedure without returning a result) and a Function (which returns a result). In VBA:

   SubroutineA

or

   Call SubroutineA 

becomes in AppleScript:

SubroutineA()

Except that when you are calling a handler from within an application tell block, as you will be doing virtually all the time, you must precede the call with the keyword my:

tell application "Microsoft Word"

    my SubroutineA()

end tell

or you will get an error. (Or you could use the synonym of me after the handler name, if you prefer: SubroutineA() of me.) It‘s perfectly OK to use 'my' even when not in a tell block, so just do it every time and you can‘t go wrong. If you‘re wondering, the 'my' tells AppleScript that the user term SubroutineA belongs to the script itself, and not to the application (Word).

Similarly, if passing parameters to the subroutine, the VBA:

   SubroutineA param1, param2

or

   Call SubroutineA(param1, param2)

both become, in AppleScript:

my SubroutineA(param1, param2)

And the VBA:          

   theResult = FunctionB(param1, param2)

or

   Set theResult = Call FunctionB(param1, param2)

both become, in AppleScript:

set theResult to my SubroutineA(param1, param2) 

Again, a reminder that in all cases this SubroutineA is just a name followed by parentheses – it is not preceded by the word 'Sub' or 'Function' but rather by the obligatory 'on' or its synonym 'to'. It will look something like this:

on SubroutineA(param1, param2) 

        display dialog "Here's " & param1 & " and " & param2                        

end SubroutineA

Note that if you are sending commands to Word or Excel or any other application inside the subroutine, you must include a new tell block to that application there, even if the call to the subroutine was itself within a tell block to the very same application: that "calling" tell block has no force inside another subroutine (handler). It will most often happen, especially converting from VBA macros, that both the calling top-level script (or handler – you can call one subroutine from another too) and the called handler send commands to Word, or Excel, or PowerPoint and both contexts need their own tell block to that application.

Note also that "function" handlers that return results are no different in AppleScript from ones that don‘t:

on SubroutineA(param1, param2)

    set someText to "Here's " & param1 & " and " & param2

    return someText

end SubroutineA

might well be the handler called by

set theResult to my SubroutineA(param1, param2)

Modules