Hi all,
I've been busy updating a number of my "PoBoy" applications all
month, and I'm now in the middle of redesigning one that I had originally
created just for myself and which handles the creation and management of
IniFile code.
This works as a stand-alone utility application. It has a small,
embedded dB with two tables per logged-on user in their own specified
directories. The first allows the developer to register a Delphi Project
via selecting it's bdsprj or dpr file and the directory it is fond in, along
with the path and name of the iniFile to be created, and the TIniFile VAR to
be used in it's coded creation. The second table allows the developer to
add all possible inifile calls by entering a section name, type, object
name, and default value, from drop-down lists where ever possible in a Grid.
Whether done one at a time or all at once, when ever a record is selected in
the Grid, the developer can then click a read or write button which
assembles a line of Pascal code that will read from or write to the eventual
inifile as per the parameters set in that particular record. One doesn't
need to duplicate records so that both a read and write can be made.
Each line of code either reads to or writes from a var with the same
name as the object parameter like so:
MainForm.Top := MyIniFile.ReadInteger( SectionName, 'MainForm.top',
DefaultVa;ue);
OR
MyIniFile.WriteInteger( SectionName, 'MainForm.Top', MainForm.Top);
And each record when selected, is coded based on the read or write
instruction and added to a stringlist. You can add just one or all of those
selected, either one at a time or all at the same time, and then another
button-click sends the stringlist contents to the Windows clipboard so it
can be pasted into your Delphi or other editor. This action also clears the
stringlist so that it's ready for the next command. So as an example, one
could place all his needed read code into one method with but two clicks, or
could actually place one line of code, whether it be to read or write, in
separate methods! Each time the stringlist of code is added to the
clipboard, you also have a choice of having it wrapped in a try,,,finally
block with or without it's creation and close code included, or the same but
in a try...except block. The reason I'm using standard tables instead of
in-memory tables of course is so that once a new project is registered, all
data inputted during a session will be saved and be available when ever you
get back to that project again. Each project and it's inifile calls are
indexed together so that you can have as many different projects going at
once, and as many different users as may be developing on the same machine.
Naturally though, only one user and one project can be worked on at the same
time!
This has been the way I've been using the version I built for
myself, however I have noted that some developers like to have all their
inifile code placed into a separate, globally available unit which can then
be added to the uses clause of any unit that requires such access, and so
I'm trying to include the ability to create a full unit like this as well.
The first question I have is about such an ability.
If I were to set up an option to write it all out to a separate
unit, this unit will require methods that can be called from what ever units
require inicode to be read or written. I can't see a way to handle this
semi-automatically so that the user can decide how many and what names are
given to the many possible methods they might require. But it is doubtful
that those who do use such a means would only require two methods...one to
read all of them and another to write all of them! What I could do instead
is create the unit template, add all the preformatted stuff like the Var and
uses clause, and then just allow the user to create their own methods and
then paste the same calls as above into them, but I thought I'd better ask
if anyone had any other ideas that might make this work a little better when
a unit is required?
Next, I don't know how many others use any non-standard ini calls.
For example I have a FonttoString and StringtoFont calls I use from a
separate utility unit I created, and these require formatting that is
different than what the regular ini calls use. So I'm going to add an
optional list box view in which a developer can add such methods and format
them as required. They could then be parameterized the same as the others
and the utility would know how to format their read and write calls. But
what about non-standard calls that require a separate or replacement iniFile
unit? My Font calls were originally part of such a 3rd party unit and I
simply copied them out to my own utility unit so that they were easier to
use. This utility unit in turn is added to my project template by default
so that it is always available as I more often need it then not! But others
may not do so. Would anyone suggest I add a customizable uses clause in
which units can be added/deleted as necessary when a new iniFile unit is to
be created? Then what about when such calls are made individually and
pasted into the project as above? Should I include an option for this as
well or simply let the user add them when needed manually?
Before anyone asks, the reason I'm doing this via a separate utility
application instead of working thru the Open Tools API is that even though
it is primarily designed for Delphi, it can in fact be used for any Pascal
enabled editor. And I don't know about the rest of you, but I do use my
Jedi-Editor quite a bit even when Delphi isn't loaded! This is also why I
intend on adding three additional modules to this utility as well. The
first of these will add Registry entry calls, the next will add preformatted
code templates of any kind, and the last will add preformatted and written
Resource strings. This last part I now have a second utility for, and I use
it daily because by doing so it adds uniformity across my applications.
There are so many times when the exact same message must be given, whether
or not it's for the same exact reason! But there's no sense in having more
than one such utility running to do all these different things!.
So if anyone has any ideas, or concepts that could improve such a
utility, please let me know. I'll show my appreciation by adding this
utility to my other freeware "PoBoy" apps.
from: Robert Meek at: [EMAIL PROTECTED]
dba "Tangentals Design" home of "PoBoy"
freeware Windows apps and utilities
located at: www.TangentalsDesign.com
Proud to be a moderator for the
"Delphi Programming Lists" at: elists.org
__________________________________________________
Delphi-Talk mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi-talk
