How to edit a config file

[was 1]

I have a 3rd party Help Desk executable which is deployed with it's configuration file (.cfg) to customers. I need to amend the config file (same structure as an ini file) to enter some customer specific info before the exec is run from my D2007 app. Is there a way to do this, seemingly, simple task?  I have tried using the TConfiguration code but while doing the job, it deletes all the other config data when WriteConfig is run! Thanks.

 

Andrew

[JonRobertson 66]

Have you tried using TIniFile and the various Write* methods to write the needed values to the .cfg file? If there are numerous writes, you could use TMemIniFile.

 

System.IniFiles.TIniFile

 

 

[was 1]

Yes I have, but writing  a value to a .cfg file gives me an AV so I assume those methods can't be used:

var RHini: TIniFile;

if RHini = nil then RHini:= TIniFile.Create(AppDir+'\RemoteHost.cfg');
RHini.WriteString('RemoteHost','User',UserName);
RHini.Free;

Edited April 19 by was

[JonRobertson 66]

You are likely getting an AV because RHini is not initialized to nil. As a local variable, it has a random value until initialized. You should have a compiler warning:

[dcc32 Warning] W1036 Variable 'RHini' might not have been initialized

Change your top line to:

var RHini: TIniFile := nil;

or perhaps

var RHini: TIniFile := TIniFile.Create(AppDir +'\RemoteHost.cfg');

 

[was 1]

Ah, yes, that was it. Thanks for the pointer; I missed the compiler warning. All ok now.

[David Heffernan 2344]

You need try/finally to avoid potential leaks. There are basically two main object creation patterns that you have to learn. You can't get far without them. 

[haentschman 92]

Hi...

 

Why if RHini = nil if if the variable is local ?

better:

RHini := TIniFile.Create(AppDir+'\RemoteHost.cfg');
try
  RHini.WriteString('RemoteHost','User',UserName);
finally
  RHini.Free;
end;

 

 

[was 1]

Thanks gents, noted. I was probably going to use Try/Finally in the code once I had proved the concept of using TIniFile (or something else) in the final code. Thanks for the reminder.

[JonRobertson 66]

16 hours ago, was said:

I missed the compiler warning.

Always pay attention to compiler warnings and hints. Most of the time, the compiler is being helpful. Had you resolved the compiler warning, you would have solved the issue without needing assistance. Asking for assistance isn't a bad thing, that's the beauty of forums like these. But solving issues without assistance is even better, for me anyway. 

 

My opinion is that I am not "finished" with code unless it compiles with zero compiler warnings and hints. Sometimes I even add a statement just so the compiler will be "happy".

 

I believe that W1036 should be an error rather than a warning, as using an uninitialized variable is almost always a bug in the code. I only say almost because I've learned there are exceptions to every rule.  

 

Warnings can be changed to errors at the project level. I have W1036 set to an error in my projects. This is done in project options. See this post if needed: state of an uninitialized variable

 

6 hours ago, was said:

I was probably going to use Try/Finally in the code once I had proved the concept

try/finally should be a habit when any resource is created or allocated, or a state that should be undone, such as setting Screen.Cursor or calling methods such as DisableControls/EnableControls and BeginUpdate/EndUpdate. Once you've developed the habit, you won't even think about doing it. It'll just be natural. And it'll avoid a lot of potential headache.

 

I neglected to mention it earlier because it was end of day on a Friday and I was ready to leave the office. Oops!

[was 1]

I agree and I'm not happy with having raised the issue in this forum when it shouldn't have been necessary - my mistake. Anyway, your points are noted and thank you (and others) for your guidance. However, it's a pity the docs on TIniFile don't mention the possibility of also editing ,cfg files - not that I could find (after extensive googling) anyway!

[JonRobertson 66]

39 minutes ago, was said:

it's a pity the docs on TIniFile don't mention the possibility of also editing ,cfg files

TIniFile will work on any file that conforms to the INI file format, and it seems the RemoteHost.cfg that you have uses the INI file format. But many, if not most, .cfg files will use a different format that isn't compatible with TIniFile.

[was 1]

OK, thanks. Glad that it works on my particular cfg type anyway! 

[David Schwartz 426]

On 4/20/2024 at 9:59 AM, was said:

 it's a pity the docs on TIniFile don't mention the possibility of also editing ,cfg files - not that I could find (after extensive googling) anyway!

Perhaps I'm beating a dead horse here, but I'm going to go out on a limb and guess you're fairly new to the programming game, based on this statement. Please allow me to fill in some blanks for you.

 

An "INI file" has a particular structure to it, and it's not dependent on the filename or its extension. Whomever wrote your code originally decided to use the INI file format to store the data, and also decided to use a .cfg extension on the filename. These are totally arbitrary choices. 

 

Back when INI files were first used, they did all tend to have .ini file extensions, but it's unnecessary. DOS introduced the use of "standard" file extensions and INI files were one such standard usage. Windows followed suit, as it as built on top of DOS. (CP/M probably also used INI files.)

 

Today, most people would choose a JSON file structure for a config file format. It would NOT be named .json nor .ini, but .cfg could very well be used.

 

Linux employs a LOT of config files, and they may be .config (NOT 'xyz.config' but just .config), xyz.conf, or even xyz.cf. Some are in a loose INI format, some are CSV, some are JSON, and many are whatever format the author decided to use.

 

My point here is that you're thinking that a "configuration file" is always going to use some standard format -- that's simply not the case. There's no standard way to interpret a file with a .cfg extension. But most files with a .ini extension are very likely to use the INI file format. Putting JSON data in a file with a .ini extension would be deceptive. And I'd say most files that contain JSON data do not use a .json file extension; it's just not a common practice.

 

(When DOS came along, file extensions were not used very much in other environments other than as 'hints' of sorts. But DOS used them to make it easier to know what a given file contained. So a .INI file always employed an INI file format; likewise, files with .txt, .doc, .ws, .wp, .obj, .lib, .exe, .com, and other extensions all had the same types of contents and could be opened with a specific tool. But .tmp is one that's used for any kind of temporary file, regardless of what the format of data in them might be.)

 

Linux does not make any assumptions about what format the data in a file might be based on given its file extension. Mac is based on Unix, and does not care either. On the other hand, Windows itself does. 

 

People who write apps with Delphi ... not always. 

 

So use the file extension as a guide towards what the internal file format might be, but don't bet your life on it.

 

[was 1]

 

13 hours ago, David Schwartz said:

My point here is that you're thinking that a "configuration file" is always going to use some standard format -- that's simply not the case. There's no standard way to interpret a file with a .cfg extension. But most files with a .ini extension are very likely to use the INI file format. Putting JSON data in a file with a .ini extension would be deceptive. And I'd say most files that contain JSON data do not use a .json file extension; it's just not a common practice.

Interesting, I hadn't fully appreciated this as I've never specifically dealt with cfg files before. Thanks for the detailed historical explanation - very useful.