Re: Implementing a Macro Language

From: Jonathan Wood (jwood_at_softcircuits.com)
Date: 06/11/04 

Date: Fri, 11 Jun 2004 08:53:17 -0600

Well, no one said it would be too easy. However, for example, in the case of
dialogs, I was thinking it would simply be enough after the dialog box
closes to simply store the settings chosen. There is no reason to record
which buttons were clicked, etc.

Changing positions in the file being edited and selections and typing data
are a bit more complicated, especially due to some specific of the
application, but I don't see anything that is too hard.

If the macro language needs to support constructs such as IF statements and
For and WHILE loops, then obviously that can get to be pretty darn involved.
But I think my application would benefit from a simple macro language that
does include support for that sophisticated of a macro language. 

-- 
Jonathan Wood
SoftCircuits
http://www.softcircuits.com
Available for consulting: http://www.softcircuits.com/jwood/resume.htm
"Dave" <noone@nowhere.com> wrote in message
news:ejZMWJ8TEHA.2908@TK2MSFTNGP10.phx.gbl...
> creating a macro record/playback mechanism like that is not easy by any
> means unless the program you are doing it for is extremely simple.  you
have
> to take into account not only keyboard actions but also mouse selections
and
> maybe even mouse motions if you are doing any graphics editing or
selection.
> also remember that it has to handle error conditions that may occur and
> popup dialogs like the file open or print dialogs that can be slightly
> different on different os versions.  if you have a spread*** you need to
> determine how to reference cells and store their locations in the macro,
> plus handle arrow and tabs between them... for forms with different types
of
> fields and buttons you have to know how to handle the input for each type
of
> control you have, like text fields, list boxes, combo boxes, radio
buttons,
> etc... each of which is handled a bit differently.  and you have to be
> careful about how you save the identifiers of those controls so that if
you
> update the software a recorded macro doesn't break...  and lots more
> depending on how complicated your application is.
>
> "Jonathan Wood" <jwood@softcircuits.com> wrote in message
> news:eOfiM$7TEHA.3664@TK2MSFTNGP12.phx.gbl...
> > Joseph,
> >
> > > Define what you mean by "macro"? Do you mean recorded keystrokes and
> mouse
> > clicks? If so,
> > > dream on, because there have been many failed attempts to do this in
the
> > past. Geometry
> > > can't work, and most everything else fails, also. The whole reason COM
> was
> > invented was to
> > > provide an abstract interface which said WHAT to do, decoupling it
from
> > HOW to do it. It
> > > has either succeeded spectacularly or failed of its own weight, but
> > whatever you believe,
> > > it is going to be with us for the foreseeable future. .NET corrects
most
> > of the
> > > difficulties. By choosing to ignore both, you are going to find that
> > remote control of
> > > apps is going to be incredibly difficult.
> >
> > By macro, I mean something that can record program operations and replay
> > them automatically. I wasn't really thinking in terms of mouse clicks,
but
> > rather selected operations.
> >
> > I don't quite follow your general tone here. I've seen dozens and dozens
> of
> > applications that implement some sort of simple macros so obviously it
can
> > be done and is not that difficult.
> >
> > I'm glad to hear you like COM. Too bad it's on it's way out.
> >
> > > If instead you mean some sort of interpretive language, there are more
> > available than you
> > > can shake a stick at. A google search should reveal a large number of
> > them, including
> > > tcl/tk, python, perl, etc.
> >
> > I don't see what good that does me. So I find an article on perl, does
> that
> > mean I'm suppose to write my application to understand perl statements?
> >
> > -- 
> > Jonathan Wood
> > SoftCircuits
> > http://www.softcircuits.com
> >
> >
>
>