Zitat von
Pfoto:
Planst du eine Abfrage einzubauen, ob ein Verzeichnis Admin-Rechte
braucht, so dass die Option "portable Version" deaktiviert ist?
Den Wizard und das Handling usw. wollte ich bewusst aus der
Unit ausklammern und nur exemplarisch in der Demo zeigen, denn das lässt sich allgemein kaum machen. Das kann jeder selbst überlegen wie detailliert welche Optionen angeboten werden sollen und wie der entsprechende Dialog aussehen soll.
Die
Unit an sich soll wirklich nur bei der Verwaltung des Speicherortes helfen.
Heißt: Welche Optionen du dem Benutzer anbietest und welche ggf. deaktivierst, liegt an dir. Du könntest ja, wenn der Benutzer die portable Option anklickt, vorher kurz eine Datei im Exeverzeichnis anlegen um zu schauen ob das geht bevor du die Seite umschaltest. Ich schaue einmal ob ich eine schönere allgemeine Lösung sehe, aber ich denke so einfach ist das nicht (Stichwort Netzwerkverzeichnisse, usw.).
Zitat von
Pfoto:
Schade ist, dass man für jede Art des Speichern / Ladens die Implementierung
erweitern muss, bei einer abgeleiteten Version kommen ja noch die
Sicherheitsabfragen hinzu.
Musst du ja nicht. Du musst nur die Implementierung von TAppData verändern, nicht die von SJConfigUtils.pas.
Und wie in dem Beispiel TAppData musst du dich ja sonst auch um die Speicherung kümmern, nur dass du so dich nicht darum kümmern musst, dass die Datei geöffnet wird usw. und wo diese liegt.
Im Grunde musst du nur die Zeilen mit TryReadString bzw. WriteString duplizieren. Die Abfragen müssen nicht jedesmal wiederholt werden!
Beispiel:
Delphi-Quellcode:
begin
if Ini.SectionExists('Userinfo') then
begin
fUserName := TryReadString('Userinfo', 'Username');
end
else
raise ELoadConfigException.Create(Format(sErrorLoadingConfig + sDLB
+ sIniSectionNotFound, ['Userinfo']));
end;
Weitere Abfragen kannst du jetzt direkt da hineinpacken.
Delphi-Quellcode:
begin
if Ini.SectionExists('Userinfo') then
begin
fUserName1 := TryReadString('Userinfo', 'Username1');
fUserName2 := TryReadString('Userinfo', 'Username2');
fUserName3 := TryReadString('Userinfo', 'Username3');
fUserName4 := TryReadString('Userinfo', 'Username4');
fUserName5 := TryReadString('Userinfo', 'Username5');
fUserName6 := TryReadString('Userinfo', 'Username6');
...
end
else
raise ELoadConfigException.Create(Format(sErrorLoadingConfig + sDLB
+ sIniSectionNotFound, ['Userinfo']));
if Ini.SectionExists('UserDataXYZ') then
begin
fUserData1 := TryReadString('UserDataXYZ', 'UserData1');
fUserData2 := TryReadString('UserDataXYZ', 'UserData2');
fUserData3 := TryReadString('UserDataXYZ', 'UserData3');
fUserData4 := TryReadString('UserDataXYZ', 'UserData4');
fUserData5 := TryReadString('UserDataXYZ', 'UserData5');
fUserData6 := TryReadString('UserDataXYZ', 'UserData6');
...
end
else
raise ELoadConfigException.Create(Format(sErrorLoadingConfig + sDLB
+ sIniSectionNotFound, ['UserDataXYZ']));
end;
Mir ist da keine universellere Lösung eingefallen.
Ich könnte höchstens die TryReadString mit weiteren Typen mit in SJConfigUtils.pas nehmen, aber ich fand das da sinnvoller.
Zitat von
Pfoto:
Ich arbeite bei mir zur Zeit mit einer
Xml-Datei. Deren Werte können - wenn
sie einmal an einer Stelle definiert sind - automatisch als Stream, als Datei
oder als Wert in die Registry geschrieben / geladen werden.
Wenn du einen Stream hast, kannst du ja direkt die Streammethoden verwenden und INI oder Registry erst gar nicht beachten. Und die Werte dann ausgelesen als Eigenschaften in TAppData zu definieren oder so ist ja kein Muss, das kannst du ja weiter wie bisher nutzen.
// EDIT:
Weitere Demos mit Streams und so werden natürlich noch folgen, aber das ist halt ein wenig Arbeit noch.
