Re: Implementing a Macro Language

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Kurt Grittner (grittkmg_NO_SPAM__at_mailbag.com)
Date: 06/14/04


Date: Mon, 14 Jun 2004 15:36:26 -0500

Hello again Jonathan,

On Mon, 14 Jun 2004 10:14:54 -0600, "Jonathan Wood"
<jwood@softcircuits.com> wrote:

>Kurt,
>
>Did you use COM automation, or some custom solution?
>

I have used both. It seems that you are leaning towards COM.

>
>Well, if I implemented COM Automation, then I assume they'd be issued
>cross-process via another program. But I was wondering about something
>simpler. Macros would be loaded from and saved to disk but I didn't plan to
>store them in text format.
>

Indeed a COM based automation project runs out of process. Retro
fitting connection points into an existing MFC app. is doable.
However, it may actually be easier for you to start with the wizard
and generate a new automation project and then paste your code into
it. Many details will be handled for you that would otherwise tend to
mystify the uninitiated. Or you could go with an embedded ActiveX
control if you want to build your product into a customer's document.

>
>Probably a subset. I don't really see a reason to automate setting options,
>for example. While search and replace options will definitely need to be
>automated.
>

Cool. Start with search and replace as the only automation method.
Get that working first, then add more if you like it.

>
>It may change a little over time, mostly to handle new features added to the
>program.
>

A neat trick is to make the caller identify the version of the
language he expects to be calling as one of the first things he does.
Then backward compatability is easier.

>
>They could. I'm not sure why this would be an issue unless you have COM
>Automation in mind.
>

It's an issue if the customer expects to be able to do other things
besides wait for your program to finish. Beware of the message queue
filling up. This is the bane of the MS-Office automation world.
Syncronizing, waiting, pumping messages may all be needed.

>
>Right. Although I was thinking of "compiling" the instructions when they are
>saved in the program, thereby storing macro information that could be
>processed faster.
>

Well, if you have a COM interface, then it is visible to any
VB/VBA/VBS program. People can start coding to with a Visual Basic
program right away... you wouldn't have to do anything language like.
You would only have to provide the methods and properties and make
sure they work properly.

>
>Thanks.

You are welcome.

Kurt



Relevant Pages

  • Re: Implementing a Macro Language
    ... > automation in mind. ... Did you use COM automation, or some custom solution? ... Macros would be loaded from and saved to disk but I didn't plan to ...
    (microsoft.public.vc.mfc)
  • Re: Late binding Access from Excel
    ... programming language afterall VB is VBA's big brother, ... An Automation infrastructure. ... VBA is hosted by other COM-based applications to ...
    (microsoft.public.access.modulesdaovba)
  • Re: Terminology: Inheritance through a component
    ... If you want data inheritance you must support it, ... > and containing an object of the base class is one way of doing that. ... LSP is supported in your language. ... These kinds of phrases are familiar to anyone using the automation products ...
    (comp.object)
  • Re: Using GUI Scripting for automated testing?
    ... programmer already knows as its scripting language. ... And testers are expected to already know/use a language? ... don't make any inroads into the overall test automation ... designing has tremendous advantages over their system. ...
    (comp.software.testing)
  • Re: Stupid question about exporting a COM/.Net object model in my programs
    ... >>> them to be automated by any language that can call COM objects. ... This is something that must be licensed from Microsoft ... It has been my understanding that providing a scripting language is ... essential to being able to use the term "Automation" as Microsoft defines ...
    (microsoft.public.vb.general.discussion)