Subj : Re: automate a process
To   : borland.public.cpp.borlandcpp
From : Ed Mulroy [TeamB]
Date : Thu Aug 26 2004 08:06 am

> ... what is the best way ...

People always ask that.  Normally there is no "best way".  There are 
plenty of ways to do most things and usually any of several of them 
are acceptable with no one standing out as a clear best method.

I always did it in the manner you describe, provide an interface which 
displays choices from which the user can select.  In the general case 
some of the selections demand a bit more information so the initial 
selection is of a class of thing to set up and another window or 
dialog box is displayed in which the details of that selection are 
set.

It is very limiting to expect what is to be saved will only be yes/no 
answers or selections from a list.  Build in some ability to have the 
user enter a string into an edit control.

As tasks such as this commonly grow it may be useful to create an 
input dialog with an array of controls and, as it is initialized, pass 
through an information structure enabling and hiding controls and 
setting their text so that the input dialog can be configured to be 
for this or for that task.  While there undoubtedly will be several 
input dialogs, having that configurable one as part of the program 
greatly simplifies the task when your customer does his inevitable 
"oh, by the way, we want to add a new item".

Saving and restoring from a file is fairly simple.  I prefer to save 
more than the state of a control.  Instead I save a couple of numbers 
along with it, a number for each of which selection and which control, 
a number which says what kind of item is saved, state or text, and if 
text, a number which is the number of characters of text and then the 
state.  I create a general class for each of a control state which is 
a number and one which is text and put the logic to save or restore it 
in that class so that it need not be re-written each time.

A couple of things to consider:

There is the temptation to make the saved file as small as possible. 
The result is that the saved items are small and difficult for you to 
manually decipher which means a high probability for error when you 
debug.  Consider either saving items as descriptive text or in some 
other more easily deciphered form.  If that is impractical then 
consider a feature which writes the configuration to a text file 
saying what the settings are in plain language.

I have found it useful to keep backup files.  When the user saves a 
new configuration, rename the old configuration file so that it is 
still available.  I normally keep up to 5 generations of such files 
(even more when still under development).  I usually just number them, 
for example filename.000 through filename.005.  When the gear starts 
doing strange things this allows you to revert to a previous 
configuration.

The issue of where to find configuration files can be more of a 
problem than it seems at first.  An easy way to deal with that is to 
have the end application be the item which runs the configuration 
program.  When it calls the program it should pass a command line 
argument which specifies the path it uses to configuration files.  It 
should also pass a command line argument which is specifically for the 
purposes of determining that the config program was called from the 
end application so that if the user starts the config program manually 
it can detect that it is in "play mode" and shouldn't modify anything 
on the disk.

..  Ed

> mike wrote in message
> news:412d750e@newsgroups.borland.com...
>
> Hi,
>
>  i wanted to know an easy way on how to automate a process in 
> windows. for example, i want to automate a application by clicking 
> buttons and saving files. i wanted to write another application that 
> does this for me. what is the best way and how do you go about doing 
> this?

.