INI problem

[Fr0sT.Brutal 900]

1 hour ago, PeterBelow said:

Are you also aware of the legal repercussions that may have? It's of course OK if you only use the program on your own computers, but if you sell it to clients it opens you up to litigation. If the program is infected on the client's computer and then causes damage there the client could sue you, since the program does not follow accepted safety standards for software. Depends on your countries legislation, of course.

That's nonsense. Nobody forbids you to install a software where you like (as long as it's good software; MSVS is NOT). Obviously any location other than PF should be protected by an admin or left as is accepting all the risks.

[Mike Torrettinni 198]

1 hour ago, PeterBelow said:

Are you also aware of the legal repercussions that may have? It's of course OK if you only use the program on your own computers, but if you sell it to clients it opens you up to litigation. If the program is infected on the client's computer and then causes damage there the client could sue you, since the program does not follow accepted safety standards for software. Depends on your countries legislation, of course.

That's interesting. From all the stuff that you can sue/get sued in US, also usually about the software the issue is late/non delivery, extra charges, quality... but, I've never heard of a case like this. Do you have any links about such case? What was the actual lawsuit about, what kind of the damage was caused? What country was that?

[Attila Kovacs 629]

52 minutes ago, Mike Torrettinni said:

causes damage there the client could sue yo

"Accepted safety standards" no such thing. 

He can sue one for many other reasons.  Insure yourself.

[corneliusdavid 214]

4 hours ago, Fr0sT.Brutal said:

This is good but requires an account for each user. Moreover, in theory there could be some settings that affect pre-connect state

This is getting off-topic but... I never use the database-level account feature but use one application-level account to connect to the database then provide a login that checks against a user record for authentication. So if your application is built to require database account credentials before connecting, then you're right, the approach I suggested would not work.

[PeterBelow 238]

23 hours ago, Mike Torrettinni said:

That's interesting. From all the stuff that you can sue/get sued in US, also usually about the software the issue is late/non delivery, extra charges, quality... but, I've never heard of a case like this. Do you have any links about such case? What was the actual lawsuit about, what kind of the damage was caused? What country was that?

I don't know much about the US legal system, other than that it is weird by german standards and have no actual case I could point to. But in my opinion a known safety problem like the one this discussion is about would be a quality issue. Of course if the client decides to use such an unsafe installation folder and the possible risk is spelled out in the installation guide then it is his problem.

As far as I'm aware  (and i'm definitely not a lawyer) in Germany software is treated like other products (hardware) now as far as consumer protection legislation and liability is concerned, so damage caused by faulty software could be reason for a (private) lawsuite. In this particular case it would probably boil down to how much knowlege of the risk involved can be reasonably expected of the user installing the software...

[Pat Foley 51]

Consider MemInifile.setStrings(SL) I use it for Demos. Using it seems to reduce waking the Antimal. 

 

  const Brand = 'PF';
  const wrappedBrand = '\'+Brand+'\';
  var IniNotFound: Boolean;
  var BrandNotfound: BooLean;
  var iniDir := Tpath.GetPublicPath;
  var AppHappyName := Application.Title;

  //following yielded /appdata/Roaming
  //PathedIniFile := System.SysUtils.GetHomePath + Application.Title + '.Ini';

  var
  PathedIniFileName := iniDir + wrappedBrand + AppHappyName + '.Ini';
  IniNotFound := not fileexists(PathedIniFileName);

  BrandNotfound := not DirectoryExists(iniDir + '\' + Brand);
  if BrandNotfound then
    ForceDirectories(iniDir + '\' + Brand);

  InidataFile := Tmeminifile.Create(PathedIniFileName);

  if IniNotFound then
  begin
    var
      SL: TStringList;
    SL := TStringList.Create;
    try
      SL.Text := cDefaultIni;
      IniDataFile.SetStrings(SL);
      IniDataFile.UpdateFile; // comment out for Demo
    finally
      SL.Free;
    end;

  end;