Python with the VBA recording capabilities

[Alex Martelli]

"Francois Forest" <francois_forest at yahoo.fr> wrote in message
news:3AB21C3E.95DAB3D2 at yahoo.fr...
> I compared Python to VBA (not for their syntax):
>
>     VBA gives the programming capability to Applications
>
>     Python gives the programming capability at the OS level
>     (as shell scripts traditionally did )

Python (with win32com) is basically on a par with VBA in terms
of its ability to script COM object models (the pluses and
minuses of each for this task are very subtle technical issues,
and we HAVE gone into them in the past on this forum).

Whether the 'programming' goes to an Application, to 'OS level',
or wherever, has zero to do with the language involved and
everything to do with the object-model involved.  For example,
with the 'Windows Scripting Host' object model, 'Scripting
Runtime', etc, VBA can just as well be used to automate OS
level tasks (though most users appear to prefer scripting
languages, such as VB Scripting Edition, for such tasks, still
VBA is quite able to perform them too).

Python has other, additional capabilities that do not rely on
scripting a COM/Automation object model (which VBA also does
to a very limited extent, for legacy-compatibility purposes,
but _almost_ all it does is scripting various object models --
that's how it interacts with its forms and the controls on
them, for example, although direct access to the Win32 API's
_is_ also feasible).


> VBA has the RECORD capability that transform any sequence of mouse clics
> into a program that can be edited and then adapted. This recording
> capability is amazingly efficient.

Actually (as you'd know if you had ever tried integrating full
VBA support into an application), it is the application that has
to do most of the work for this purpose; the support actually
provided by the VBA framework for this purpose is helpful, but
quite minimal.


> Can we imagine to add this feature to any current GUI (kde and others) ?

No, I can't imagine that; I don't see where the GUI gets into
the macro-recording process -- it's the _application_ (in VBA's
case, but I don't see much of an alternative?) that needs to
have a mode where keystroke, mouseclicks etc get 'recorded'
(by suitable calls that the application will make to the
recording utility) in terms that are semantically meaningful
on the application's object-model.

We do have (laying around somewhere) a generic COM recorder
we had developed to allow the 'capture and playback' mode of
our own applications to also produce editable scripts (at
first in our proprietary scripting language, with some idea
on how to generalize that), but we never invested the huge
amount of work to turn the proof-of-concept prototype into
production-level infrastructure -- our existing 'capture and
playback' having been deemed perfectly adequate for its
needed uses (basically, allowing some sequence of user actions
that reveals an application defect in some pre-release
version to be saved, then repeatedly replayed as a test to
prove the defect has indeed been fixed and does not come
up again in later pre-releases and releases).  The actual
recording infrastructure is the least of it -- the really
hard stuff is peppering the _application_ with suitable calls
to the recorder, to register relevant events at a semantically
appropriate level...


Alex