Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.

ID: 25221, IniFile Manager ver.

by Robert Meek Email:

A Delphi Applet that provides easy creation of a complete single unit to add to your project which provides management of all inifile needs. Has many options and free-form abilities. Freeware for all Delphinians
Download Details
FTP  download also available
CDN Login Required to Download. (You will be redirected to the login page if you click on the Download Link)
To download this, you must have registered:
A free membership

For Delphi, Version 2.0  to 11.0 111 downloads
Copyright: No significant restrictions

Size: 1,303,267 bytes
Updated on Wed, 14 Nov 2007 08:07:08 GMT
Originally uploaded on Wed, 14 Nov 2007 08:07:09 GMT
SHA1 Hash: D6AB259288A3829BDF4DF2F75681FAF78844C5B6
MD5 Hash: 0E11B650DE9F9B6A5E54C85B502A1D0C

    Explore the files in this upload

Depending upon the complexity and needs of your application, you may be calling "IniFiles.pas" or some other version of this basic Delphi unit from one or even all of your own project units! Most developers whose work I've looked at seem to call it's methods, like ReadString() or WriteString() from exactly where in their code they need to access or store a value, either recreating and then free-ing the ini-file for every use. Others, tend to add the base file to only their project's mainform, reading and setting the value of numerous global variables in the Mainform's OnCreate, then saving them back to the IniFile in it's OnClose or OnCloseQuery events. And still others, tend to create a single unit in which they write all their ini-access methods, needed by their Project, calling the functions and/or procedures they write from where ever in the Project the IniFile values need to be accessed or written.

Personally speaking, I'm one of the latter group, and have for many years kept a Unit I named "AppIniU.pas" in my Project templates where every other unit in a Project developed fro the template has access to it via it being placed in their interface uses clause. I then usually add each of these Units in turn to my AppIniU unit's Implementation uses clause because I normally use form properties or some other variable within them to directly provide Values in my Set prodecures. The "AppIniU" unit is then the ONLY one that has the "IniFiles.pas" unit, or whatever 3rd party unit you might be emplying to provide inifile management in its own interface uses clause.
The big diference in the way I use such a unit however, is that instead of calling inifile methods directly from where and when I need to get and/or set their values, I instead use this unit to support individual get and set methods for each value that must be stored, and it is then these methods which in turn actually make the necessary inifile calls. And in fact, I also always write a method which creates the application's IniFile and another that frees it when it's no longer needed as well. Then instead of using a bunch of variables or having to write the same IniFile read and write code over and over throughout my project, I merely call the method for the value I need to retrieve or store, and at the exact time in the application's run that I need to do so! As you'll note in the example shown later, by employing the same naming conventions in the way I write these methods, as well as in the way I make the inifile calls from within them, it becomes very easy to write calls to them from anywhere in my project without having to refer back to my IniUnit. This is because they are all named based upon the the Key names used!

The advantages of doing things this way are numerous, but at the most basic level, it's how well it keeps things organized and easy to change by having all these calls in one place and named in the same way. Also it becomes much quicker to write these methods as well because most of the time I can merely copy and paste them together from others already written in the same unit!

I worked using this technique for handling Inifiles for a long time before I realized how easy it would be to automate the process of writing not only all these methods, but the entire unit itself! That by simply writing a little application which allows me to enter some basic information relative to a project and then the Section, Key, and Value of each call, that it could actually write all these methods for me as well as to setup and create the entire Unit as well! What I wasn't sure about, was whether or not such an automatic system could be used in the same manner as most developers work! That being simply that it would have to be updateable so that one could come back and add, edit, or delete various calls as their development project grows. After all how often do we know exactly how many inifile calls we'll need to make when we first get started? And how many times have you had to go back and change the Type of a Value, or add some kind of conversion code to make the IniFile work as wanted? I decided not to allow such questions to get in my way unless or until I found them to be completely unsurmountable, and so went to work on the problem assured that I could accomplish the creation of a Utility that would meet most if not all developer requirements!

The result of my work on this idea is "IniMan", or in it's long version, "IniFiles Manager". It is a stand-alone application using a very small embedded database that allows the developer to enter in the "Section", "Key", and "Value" required for any TIniFile, TmemIniFile, or ther TObject call, and use that data along with some basic Project information to create a single Unit in which all these calls are each wrapped in a function to get a Value and a procedure to set it. The Unit is then auto-saved to your Delphi Project Files directory where it can be added to the Uses clause of any other Unit in your Delphi project that needs access to the IniFile, allowing the developer to use these simple calls when ever and where ever they are needed! All the information, data, and a copy of the Unit is stored in the developers own dB file so that it can be updated with new Ini Items and re-created any time the developer makes changes. Then after actually working with my creation on real-world projects, I made some additional changes that allows the developer to select between using TIniFile or TMemIniFile, both provided by the IniFiles Delphi Unit, any other IniFiles unit and it's object types you might prefer wiorking with, providing the different methods each type requires, as well as adding two additional methods which make it possible to store and retrieve TFonts along with all the other types of common Values. And at the same time I included an extra Project Entry edit in which the developer can enter additions to the interface uses clause of the Unit. Lastly, I improved the entry Grid by including a separate Value edit for both Get and Set methods so for example, if one already knew what variable or property to read when setting a Value of a particular Type, the developer could enter that information directly and not have to edit the final Unit by hand! Finally, I made sure that all the Value entries made could be written either as the actual Type of the Value in question, or as some other type along with conversion code. All coding methods are exactly the same as in Pascal itself, allowing you to write the Value of a Set method for example, using any combination of variables, properties, or literal strings.
It's not can't be because it is impossible to deal with every possible alteration a developer might make using a single unit like this. But in the examples section of this file I'll show you what to watch for and the best ways to get around small problems like this. What "IniMan" CAN do it does very well, and I promise you that if you give it an honest try, you'll retain much better organizational control over your projects, and reduce the time spent writing redundant code over and over again!

Please give "IniMan" a try, and let me know if you have any ideas for improvement or the addition of new abilities. This utility will always remain freely available to all Delphi programmers as my inadequate way of thanking the community for all the help they've given me over the years, and I hope to be able to make it even better than it is right now. But I can only do so if developers like yourself provide me with honest feedback! Let me know if you're using it and if not why. What I might change to improve it. Or even if you think it is a wasted effort!

   Latest Comments  View All Add New

Move mouse over comment to see the full text

Could not retrieve comments. Please try again later.

Server Response from: ETNACDC03