Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2008-10

GetAppConfigFile

9 messages · 7 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Micha Nelissen

Hi,

Why is there a parameter to GetAppConfigFile? I'd suggest something like:

function GetAppConfigFile: string;
begin
   { first look for user specific config file }
   Result := GetAppConfigFile(false);
   if FileExists(Result) then
     exit;
   { otherwise use global one }
   Result := GetAppConfigFile(true);
end;

This would first look for the user version, then for the global variant.

(BTW: instead of Boolean, I would have liked a acLocal, acGlobal better, it's clearer to read).

Any thoughts?

Micha

Reply by email

Aleš Katona
to Micha Nelissen

Dňa So, 2008-10-04 o 12:23 +0200, Micha Nelissen napísal:

Show quoted text 20 lines
Hi, Why is there a parameter to GetAppConfigFile? I'd suggest something like: function GetAppConfigFile: string; begin { first look for user specific config file } Result := GetAppConfigFile(false); if FileExists(Result) then exit; { otherwise use global one } Result := GetAppConfigFile(true); end; This would first look for the user version, then for the global variant. (BTW: instead of Boolean, I would have liked a acLocal, acGlobal better, it's clearer to read). Any thoughts?

Please don't break this yet again. It's bad enough FPC completely ruined config dir paths on some OSes between versions as is.

I don't see a particular problem with the boolean var.

Ales

Show quoted text 5 lines
Micha _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Vinzent Höfler
to Micha Nelissen: Why is there a parameter to GetAppConfigFile? I'd suggest something like: function…
Micha Nelissen wrote 11 lines
Why is there a parameter to GetAppConfigFile? I'd suggest something like: function GetAppConfigFile: string; begin { first look for user specific config file } Result := GetAppConfigFile(false); if FileExists(Result) then exit; { otherwise use global one } Result := GetAppConfigFile(true); end;

No. Because one wants the path name of the local configuration, checking for existance of the file is a completely different issue.

Often, after a first install, the local config does not exist yet (or the user may have deleted it), so your proposed approach would completely disable the local config then, because without the proper path name there's no chance to recreate the file. Considering that the global config is not even writable in most sane circumstances, this would also disable storing any settings in the file by the application.

In short: It would render the whole thing quite useless.

(BTW: instead of Boolean, I would have liked a acLocal, acGlobal better, it's clearer to read).

Agreed. But it's as it is, I guess. It was broken so often, can't do that again... ;)

Vinzent.

Reply by email

Micha Nelissen
to Vinzent Höfler
Vinzent Höfler wrote
Often, after a first install, the local config does not exist yet (or the user may have deleted it), so your proposed approach would completely disable the local config then, because without the proper

No, when saving you always save to the local config file, because most of the time you're not allowed to write to the global one.

Loading is more common than saving, that's the use case I am talking about.

Micha

Reply by email

Michael Van Canneyt
to Micha Nelissen: Why is there a parameter to GetAppConfigFile? I'd suggest something like: function…
Micha Nelissen wrote 20 lines
Hi, Why is there a parameter to GetAppConfigFile? I'd suggest something like: function GetAppConfigFile: string; begin { first look for user specific config file } Result := GetAppConfigFile(false); if FileExists(Result) then exit; { otherwise use global one } Result := GetAppConfigFile(true); end; This would first look for the user version, then for the global variant. (BTW: instead of Boolean, I would have liked a acLocal, acGlobal better, it's clearer to read). Any thoughts?

As far as I'm concerned, you can add this as an overloaded version, but don't change the boolean. The API is in use too long for that, and such a change would only reflect your personal preference.

Michael.

Reply by email

Vinzent Höfler
to Micha Nelissen: No, when saving you always save to the local config file, because most of the time you're…
Micha Nelissen wrote 7 lines
Vinzent Höfler wrote: > Often, after a first install, the local config does not exist yet (or > the user may have deleted it), so your proposed approach would > completely disable the local config then, because without the proper No, when saving you always save to the local config file, because most of the time you're not allowed to write to the global one.

Yes, but your proposal would never return the file name of a local config if it doesn't exist in the first place, so how would an application find out where it's supposed to create it?

Loading is more common than saving, that's the use case I am talking about.

Well, and that use case usually involves loading *both* files, first the global settings and then optionally tweaking it with a user specific configuration. For those cases your approach wouldn't work neither.

Vinzent.

Reply by email

Graeme Geldenhuys
to Felipe Monteiro de Carvalho
Felipe Monteiro de Carvalho wrote
The parameter exists to choose if you wish the local or global config file. Please don't change this.

+1

I have cases in certain projects where I want to look at global and sometimes and local config files. The current way is flexible for that.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email