Re: Implementing a Macro Language
From: Kurt Grittner (grittkmg_NO_SPAM__at_mailbag.com)
Date: 06/14/04
- Next message: Stephen Kellett: "Re: Debug, Release and Libraries"
- Previous message: Johan Rosengren: "Re: Overriding a variable - changing it's type in the base class"
- In reply to: Jonathan Wood: "Re: Implementing a Macro Language"
- Next in thread: Jonathan Wood: "Re: Implementing a Macro Language"
- Reply: Jonathan Wood: "Re: Implementing a Macro Language"
- Messages sorted by: [ date ] [ thread ]
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
- Next message: Stephen Kellett: "Re: Debug, Release and Libraries"
- Previous message: Johan Rosengren: "Re: Overriding a variable - changing it's type in the base class"
- In reply to: Jonathan Wood: "Re: Implementing a Macro Language"
- Next in thread: Jonathan Wood: "Re: Implementing a Macro Language"
- Reply: Jonathan Wood: "Re: Implementing a Macro Language"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|