Re: Implementing a Macro Language
From: Joseph M. Newcomer (newcomer_at_flounder.com)
Date: 06/11/04
- Next message: KS: "Re: FindWindow is hanging...."
- Previous message: LarrySS: "createprocesswithlogonw"
- 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: Fri, 11 Jun 2004 17:59:53 -0400
See below...
On Fri, 11 Jun 2004 10:00:41 -0600, "Jonathan Wood" <jwood@softcircuits.com> wrote:
>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.
>
****
And how, exactly, are the settings "retained"? For a check box, or edit contorl, the
implementation is trivial. But a list box? Combo box? List control? Tree control? This is
where a lot of the schemes that try to do this collapse. I've seen them collapse. I've
even tried to rescue a couple, and it is hard.
****
>> 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.
****
SetCurSel() in an Edit control. Imagine figuring out text selection in an app that does
not use edit controls (e.g., Word)
****
>
>> 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.
>;-)
****
The problem is the illusion you have thought everything through. I'm involved right now in
a project where a lot of very bright people spent a year on the design, and I'm sitll
finding holes in their design. And they're finding holes in my implementation. And the
design looked SO good! (My implementaiton, of course, is perfect. And if you believe that,
I have this nice bridge in New York City that you might want to buy)
>
>> 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.
****
I;ve built these without using COM. They are very hard to get right.
By the way, I did one about six months ago that uses XML for its saved state. I have one
major caveat, which I planned for, and it has saved me several times in the intervening
months. Think "schema evolution". That is the other major downfall of most of these
systems.
Add a control. Delete a control. Change the caption on a control. Change the number of
selections in a listbox or combobox. Change their sort order. Change the strings that
represent the options. Internationalize. Move across machines. Import/export. Remove a
control and put it back as a different type of control.
I built a lot of mechanism in to handle all these cases. It got it mostly right, but
"mostly" isn't the same as "completely", and we've got some issues of legacy maintenance
of the settings, particularly how to import a December config file into the February
version, where there is no reasonable default for some of the new controls that were added
in late January (DC calibration offset voltage was added to the firmware, then to the
interface, then necessarily to the XML, but what is it? Zero may not be the right default,
but the user needs to know that there was no calibration voltage set! Little things like
this become serious problems)
*****
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
- Next message: KS: "Re: FindWindow is hanging...."
- Previous message: LarrySS: "createprocesswithlogonw"
- 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
|
