Ini Datei kann nicht geschrieben nach Benutzerwechsel

hansg · Verfasst: Sa 28.04.07 13:55

Hallo zusammen,

ich verwende in einem Programm die Ini-Funktion, was soweit auch einwandfrei funktioniert.
Die Ini-Datei wird im Windowsordner angelegt.

markieren

Delphi-Quelltext

1:
2:
3:

   ini:=TiniFile.create('mtStamm.ini');
   ini.WriteString('Data', 'User', MVN);
   ini.free;

Wechselt man den Windowsbenutzer, und man startet das Programm kann die Ini-Datei nicht geschrieben werden, es kommt eine Fehlermeldung das man keinen Zugriff hat.
Melde ich mich wieder mit meinem Namen an geht es.
Hat jemand einen Tip für mich?

_________________
Gruß Hans

GTA-Place · Verfasst: Sa 28.04.07 14:00

Du kannst nicht als eingeschränkter Nutzer in das Windows-Verzeichnis schreiben. Warum auch? Was hast du darin verloren?

_________________
"Wer Ego-Shooter Killerspiele nennt, muss konsequenterweise jeden Horrorstreifen als Killerfilm bezeichnen." (Zeit.de)

hansg · Verfasst: Sa 28.04.07 14:33

GTA-Place hat folgendes geschrieben:

Du kannst nicht als eingeschränkter Nutzer in das Windows-Verzeichnis schreiben. Warum auch? Was hast du darin verloren?

Hallo,

die Ini-Dateien werden ja immer im Windowsordner angelegt, macht eigentlich jedes Programm so.
Außnahme man gibt einen Speicherort vor.

_________________
Gruß Hans

Gausi · Verfasst: Sa 28.04.07 14:41

Das war unter Win9x/Me so, aber seitdem Windows ein Mehrbenutzer-System ist, sollte das eigentlich nicht mehr so sein. Und seit Vista sind solche Programme nicht mehr wirklich lauffähig, sondern einfach nur nervig.

Wenn man inis verwendet, dann gehören sie in das Anwendungsdaten-Verzeichnis des Users, also c:\Dokumente und Einstellungen\{user}\Anwendungsdaten. Wie man dieses Verzeichnis findet: Forensuche anwenden ;-)

_________________
We are, we were and will not be.

jaenicke · Verfasst: Sa 28.04.07 15:37

Gausi hat folgendes geschrieben:

Das war unter Win9x/Me so, aber seitdem Windows ein Mehrbenutzer-System ist, sollte das eigentlich nicht mehr so sein. Und seit Vista sind solche Programme nicht mehr wirklich lauffähig, sondern einfach nur nervig.

Nicht mal Win9x... Schon da stand in den Entwicklungsrichtlinien drin, dass die Praxis von Windows 3.x (also von vor Windows 95^^), INIs im Windows-Verzeichnis zu plazieren, nicht mehr verwendet werden sollte...

Denn INIs waren mit der Registry von Windows 95 obsolet und sollten nicht mehr verwendet werden. Warum viele statt der Registry für Einstellungen immer noch INIs verwenden ist mir ohnehin ein Rätsel (außer für portable Software für USB-Sticks natürlich). Wenn es größere Datenmengen sind, ok, dafür ist das Anwendungsdaten-Verzeichnis bzw. für Einstellungen das Verzeichnis Lokale Einstellungen\Anwendungsdaten da, aber dann sinds ja keine INIs sondern Datendateien.

Aber meist sind es ja nur ein paar Strings, und solche Einstellungen gehören in die Registry... Aber naja, wenn mir als Administrator ein Programm über den Weg läuft, das sich nicht an solche Standards hält, dann wird es eben bei uns nicht eingesetzt, fertig.
Denn da ist schon so viel Zeit bei draufgegangen solche Software für alle User lauffähig zu bekommen, dass ich die Nase voll habe.

PS: Das ist jetzt nicht speziell gegen dich gerichtet, hansg, ich bin nur ein wenig dünnhäutig was das Thema angeht. Denn warum immer noch immer mal wieder jemand sagt, dass INIs ins Windows-Verzeichnis gehören, kann ich einfach nicht nachvollziehen, schließlich ist das jetzt seit 12(!!) Jahren veraltet, und das ist beim PC ja nun eine sehr lange Zeit...

hansg hat folgendes geschrieben:

die Ini-Dateien werden ja immer im Windowsordner angelegt, macht eigentlich jedes Programm so.

Da ist mir in den vergangenen 3 Jahren genau ein Programm begegnet... Dierckes GIS, das eine diercke.ini im Windows-Verzeichnis anlegt. (Und dann auch noch selber bei AddOns damit durcheinander kommt, weil die einfach die ganze INI überschreiben, sodass man das mühsam per Hand zusammentragen muss... Die AddOns sind nämlich einfach SFX-Archive^^)
Leider gibt es für dieses Programm keine echte Alternative, so dass halt mittlerweile viele Stunden Arbeit in der Einrichtung dieses einen Programms stecken...

hansg · Verfasst: Sa 28.04.07 17:56

Hallo,

danke für die Infos, werde ich mal die Handhabung mit der Ini ändern.
Habe aber da mal 2 Fragen zu.

1. Wie kann ich die INI-Datei Userabhängig (Profile) verwalten ?

2. Es gibt doch eine Option das die INI-Datei im dem Ordner angelegt wird wo das Programm gestartet wurde, ich
finde leider nichts dazu in der Hilfe.

_________________
Gruß Hans

JayEff · Beiträge: 2971 Windows Vista Ultimate D7 Enterprise

Eine userabhängige Speicherung erreichst du über die Registry (HKEY_CURRENT_USER) oder über das Anwenderdaten-Verzeichnis, siehe ein paar Posts weiter oben. Wenn du die ini in den Programmordner speichern willst, benutze ExtractFilePath(ParamStr(0)) + 'config.ini' als Dateinamen. Davon ist aber abzuraten da oft nur Administratoren oder höher priviligierte Benutzer in diesen Ordner schreiben dürfen.

_________________
>+++[>+++[>++++++++<-]<-]<++++[>++++[>>>+++++++<<<-]<-]<<++
[>++[>++[>>++++<<-]<-]<-]>>>>>++++++++++++++++++.+++++++.>++.-.<<.>>--.<+++++..<+.

jaenicke · Verfasst: Sa 28.04.07 18:44

Wie bereits gesagt wurde: Wenn das Programm unter Vista unter C:\Programme liegt, dann ist eine Speicherung im eigenen Verzeichnis durch die UAC zunächst nicht möglich. Wenn du das versuchst, dann kommt eine Warnung, dass das Programm Administratorrechte braucht und das Programm dann potentiell eine Gefährdung für das System sein kann.
Und Administratorrechte gebe ich nur sehr wenigen Programmen, denen ich hoffe vertrauen zu können. Ganz bestimmt aber nicht irgendeinem, das ich nicht kenne...

Was die benutzerabhängige Speicherung angeht, hier ein ganz kleines Beispiel, das du aber auch im Internet oft genug findest: :roll:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:

var
  Reg: TRegistry;
begin
  Reg := TRegistry.Create;
  Reg.RootKey := HKEY_CURRENT_USER;
  if Reg.OpenKey('Software\DeinName\DeinProgramm\1.0', True) then
  begin
    Reg.WriteString('ApplicationName', 'Mein Programm 1.0');
    Reg.CloseKey;
  end;
  Reg.Free;
end;

auslesen:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:

var
  Reg: TRegistry;
begin
  Reg := TRegistry.Create;
  Reg.RootKey := HKEY_CURRENT_USER;
  if Reg.OpenKey('Software\DeinName\DeinProgramm\1.0', False) then
  begin
    ShowMessage(Reg.ReadString('ApplicationName'));
    Reg.CloseKey;
  end;
  Reg.Free;
end;

hansg · Verfasst: Sa 28.04.07 19:03

Hallo,

da mein Programm einen vorgegeben Order bei der Installation erhält (kann nicht verändert werden - hat seine Gründe)
habe es jetzt so gelöst

markieren

Delphi-Quelltext

1:	Pfad:=ExtractFilePath(ParamStr(0)); {Liefert das Verzeichnis, in dem die EXE auch ist}

In diesem wird dann die Ini geschrieben bzw. gelesen, funktioniert auch bei verschiedenen Profilen.

@jaenicke

Danke für das Beispiel mit der Registry, habe ich mich noch nie mit beschäftigt, werde ich machen wenn ich mehr Zeit habe, blicke da im Moment nicht durch.

_________________
Gruß Hans

Ehemaliges Mitglied Erhaltene Danke: 1

Genauso schlecht, wie das Windows Verzeichnis, wenn Anwneder die Datei verändern können sollen, da im Oder c:\Programme auch nur Administratoren schreiben können. Unter XP schlecht, unter Vista eine Katastrophe.

jaenicke · Verfasst: Sa 28.04.07 21:07

Tja, wurde ja auch schon mehrfach gesagt... Aber da scheint man gegen eine Wand zu reden. Das merkt man ja dann auch daran, dass viele Programme unter Vista schlichtweg nicht mehr laufen.
Wobei man sagen muss, dass Borland mit Delphi 7 ja auch nicht gerade vorbildhaft gehandelt hat... Wobei da allerdings zumindest das Arbeitsverzeichnis vor dem Aufruf eines Dialogs gespeichert und danach wieder zurückgesetzt wird. (Schien mir jedenfalls so, genau drauf geachtet habe ich nicht.)
Dadurch kann man es (was du, Luckie, glaube ich auch vorgeschlagen hattest) einfach in der Verknüpfung ändern und es funktioniert wieder.

Naja, schlimm wird solche Programmierweise erst, wenn es sich um kommerzielle Software handelt. Da kauft man eine Software, nur um dann festzustellen, dass durch derart amateurhafte Programmierung das Programm unbrauchbar ist.
Bei Freeware kann man sie ja ohne persönlichen Verlust (von der verschwendeten Zeit mal abgesehen) einfach wegwerfen.

Übrigens steht auch in den Programmierrichtlinien, dass man Programme immer unter c:\programme unterbringen sollte und keine anderen Pfade (z.B. direkt unter c:\) verwenden sollte.
Leider gibt es da genug Software auf dem Markt, die aus mir nicht ganz nachvollziehbaren Gründen feste Verzeichnisse direkt unter c:\ verwendet, anstatt lieber sauber zu programmieren. Dass es zunächst einfacher erscheint, verstehe ich durchaus, aber was ist das für eine Lösung, wenn aus eigener Bequemlichkeit beim Programmieren die Probleme auf den User abgewälzt werden??

Naja, es bleibt nur noch zu hoffen, dass der überlastete Support jetzt bei nicht mehr funktionierender Software unter Vista ein Umdenken bewirkt.

hansg · Verfasst: So 29.04.07 08:55

Hallo zusammen,

danke für die ganzen Ratschläge und Tips.

Benutze die INI-Funktion selten, habe mal entsprechend dem Beispiel was ausprobiert:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:

procedure TForm1.Button1Click(Sender: TObject);        // Reg schreiben
var
  Reg: TRegistry;
begin
  Reg := TRegistry.Create;
  Reg.RootKey := HKEY_CURRENT_USER;
  if Reg.OpenKey('Software\Test\Testprogramm', True) then
  begin
    Reg.WriteString('Eintrag 1','Test 1');
    Reg.WriteString('Eintrag 2','Test 2');
    Reg.WriteString('Eintrag 3','Test 3');
    Reg.CloseKey;
  end;
  Reg.Free;
end;

procedure TForm1.Button2Click(Sender: TObject);        // Reg lesen
var
  Reg: TRegistry;
begin
  Reg := TRegistry.Create;
  Reg.RootKey := HKEY_CURRENT_USER;
  if Reg.OpenKey('Software\Test\Testprogramm', False) then
  begin
    label1.Caption:=(Reg.ReadString('Eintrag 1'));
    label2.Caption:=(Reg.ReadString('Eintrag 2'));
    label3.Caption:=(Reg.ReadString('Eintrag 3'));
    Reg.CloseKey;
  end;  
  Reg.Free;  
end;

Das klappt soweit auch, wie verhält sich das jetzt mit den verschiedenen Benutzern, habe die alle kompletten Zugriff
auf den Eintrag oder gibt ees da auch Einschränkungen?

_________________
Gruß Hans

JayEff · Beiträge: 2971 Windows Vista Ultimate D7 Enterprise

HKEY_CURRENT_USER ist, wie der Name schon sagt, der Bereich des aktuellen Benutzers in der Registry. Andere Benutzer erhalten einen anderen HKEY_CURRENT_USER - Bereich und damit keinerlei Zugriff auf die vorher gespeicherten Daten iirc. Ich vermute aber, dass ein Admin irgendwie auf diese Bereiche zugreifen kann...

_________________
>+++[>+++[>++++++++<-]<-]<++++[>++++[>>>+++++++<<<-]<-]<<++
[>++[>++[>>++++<<-]<-]<-]>>>>>++++++++++++++++++.+++++++.>++.-.<<.>>--.<+++++..<+.

hansg · Verfasst: So 29.04.07 16:01

Hallo zusammen,

soweit funktioniert alles.
Da ich das ganze auch verstehen möchte und nicht nur abtippen will, habe aber trotzdem noch Fragen.

Was genau bedeuten folgende Anweisungen,es geht mehr um das True und False.

markieren

Delphi-Quelltext

1:
2:

if Reg.OpenKey('Software\Test\Testprogramm', True) then  
if Reg.OpenKey('Software\Test\Testprogramm', False) then

Wofür ist die Anweisung

markieren

Delphi-Quelltext

1:	Reg.CloseKey;

Ich denke das

Reg.Free hat die gleiche wie ini.free oder?

_________________
Gruß Hans

BenBE · Verfasst: So 29.04.07 16:33

Das True in Reg.OpenKey bedeutet "Ich möchte das Öffnen erzwingen und ggf. den Schlüssel anlegen" ... Das False "Wenn's nicht ist, dann lass es halt geschlossen".

Das Reg.CloseKey gibt Resourcen frei, die durch Reg.OpenKey belegt werden (genau genommen ein Handle, was diesen Key eindeutig identifiizeirt und deinen Zugriff auf diesen angibt).

_________________

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme