Re: Implementing a Macro Language
From: Jonathan Wood (jwood_at_softcircuits.com)
Date: 06/11/04
- Next message: Jonathan Wood: "Re: Implementing a Macro Language"
- Previous message: Robert A.: "Re: DeleteDC() and DeleteObject() Question"
- In reply to: Joseph M. Newcomer: "Re: Implementing a Macro Language"
- Next in thread: Joseph M. Newcomer: "Re: Implementing a Macro Language"
- Reply: Joseph M. Newcomer: "Re: Implementing a Macro Language"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 11 Jun 2004 10:00:41 -0600
Joseph,
> Well, the way most of these macro systems work is in terms of automation,
which is why
> they look so easy. Examples include the macro systems in Word and other
Office products.
Actually, the ones I thought that looked easy do not use automation.
> What do you mean "store the strings chosen"? What if they are in list
boxes, what about
> check boxes, owner-drawn combo boxes, etc.? There aren't any "strings' in
an owner-drawn
> listbox or combo box, so what do you store? The pointer to the ItemData?
Each dialog box has a fixed number of settings. Why couldn't I simply save
those settings somewhere once a dialog is dismissed if macro recording is
on? I'm already saving those settings anyway. I realize this is not trivial
but it doesn't seem so complicated to me.
> The selection mechanism is usually a fatal problem, because so few
applications make it
> available, except possibly via COM interfaces.
I'm sorry, I do not follow what you mean here by "selection mechanism," or
how a COM interface would help here.
> Feel free to try, but I've seen so many of these efforts crash and burn
that I consider it
> futile. Especially because they spend many months on the project, and
finally we get a
> question in the newsgroup that explains what they can't do, and most of us
who reply say
> "Yes, you're right, that cannot be done".
As is generally my approach, I plan to think everything through before I
actually start to add it to my application. Thanks for your concern though.
;-)
> While there are many objections to COM as a technology, it was created to
solve a very
> complex problem, the problem of automating an app. While we may disagree
with the details
> of how COM works, nothing changes the fact that the abstract model, as
complex as it is,
> is what is needed. .NET gets rid of most of the baggage of COM while
retaining the
> functionality, which is an abstract automation interface. So what you are
attempting to do
> is to do is reinvent COM or .NET automation interfaces. I'm not sure I'd
be willing to
> tackle that with a crack team of serious Window experts, let alone on my
own.
I think you are making this more complicated than it is. I am not even
coming close to trying to reinvent COM. COM is a method of interprocess
communication. My application will need no interprocess communication in
order to automate a few of its tasks. Nor did I intend to develop a
full-featured macro language. Finally, even COM does not solve the problem
of recording macros (unless there is something I do not know about). So, in
combination with the concerns I've already articulated with regards to COM,
I've yet to hear a great argument for using a technology that is on its way
out.
-- Jonathan Wood SoftCircuits http://www.softcircuits.com Available for consulting: http://www.softcircuits.com/jwood/resume.htm
- Next message: Jonathan Wood: "Re: Implementing a Macro Language"
- Previous message: Robert A.: "Re: DeleteDC() and DeleteObject() Question"
- In reply to: Joseph M. Newcomer: "Re: Implementing a Macro Language"
- Next in thread: Joseph M. Newcomer: "Re: Implementing a Macro Language"
- Reply: Joseph M. Newcomer: "Re: Implementing a Macro Language"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|