INI, Registry, ThaXML-Library was ist sinnvoll

[Chemiker]

Hallo,

ich möchte bestimmte Daten von einer Anwendung z.B. die letzte Fensterposition speichern. Bisher habe ich das über INI – Dateien realisiert. Das soll aber nicht mehr Zeitgemäß sein.
Was ist besser euer Meinung nach, dass über die Registerdatenbank, INI – Dateien oder einer ThaXML-Library Konfigurationsdatei zu programmieren.

Bis bald Chemiker

[DeddyH]

Ich weiß gar nicht, was alle immer gegen Inis haben. Du solltest nur auf den Speicherort achten, also nicht ins Programmverzeichnis, sondern ins aktuelle Benutzerprofil. Alternativ kannst Du auch in der Registry unter HKCU speichern.

[mkinzler]

Es kommt darauf an, ob die Werte userabhängig sind oder nicht.

[DeddyH]

Naja, bei letzter Fensterposition usw. denke ich schon an benutzerdefinierte Daten.

[Luckie]

Ich würde Ini-Dateien wählen, da sie keine Baumstruktur erfordern und man für die Registry wieder einen Deinstaller mitliefern müsste.

[sakura]

Zitat:

Zitat von Luckie

Ich würde Ini-Dateien wählen, da sie keine Baumstruktur erfordern und man für die Registry wieder einen Deinstaller mitliefern müsste.

Wenn die Ini-Dateien irgendwo in den UserApp-Daten liegt, dann ist da hoffentlich auch ein Deinstaller dabei, wer will schon, dass die HDD über Zeit mit solchen Müll zugestopft wird...

...:cat:...

[Muetze1]

Und wieso ThaXML? Es gibt auch genug alternativen. Meine ist aus dem o.g. Grund zur Konfigurationsablage entstanden. Und damals brauchte ich XML, da ich dynamisch viele Objekte mit gleichen Eigenschaften speichern musste und das geht nicht ohne Hierarchie in den Konfigurationsdateien.

[Chemiker]

Hallo,

es ist schon nicht einfach.

@Muetze1: In Delphi – Treff gibt es ein Tut. über ThaXML da wird postuliert, dass es vorteilhaft wäre es statt Registry oder INI zu verwenden.

@sakura, Luckie: Man sollte schon hinter sich wieder alles aufräumen. Aber ich denke das ist bei der Registry und bei INI notwendig.

@DeddyH, mkinzler: Ich muss zugeben das ich die INI – Dateien immer im Programmverzeichnis mit abgelegt habe. Das hat auch Vor- und Nachteile, eine Arbeitskollege ist mal auf die „geniale“ Idee gekommen das Verzeichnis ‚Eigene Dateien’ von c:\ nach d:\ zu verschieben und hatte dann anschließend erhebliche Probleme.

Also wenn ich ein Fazit ziehen soll, so würde ich sagen dass ich weiter auf INI – Dateien setzen kann.
Ich habe auch etwas bedenken in der Registry rumzufummeln. Weil sich ein Fehler dabei, doch sehr unangenehm auswirken kann.

Bis bald Chemiker

[bigg]

Zitat:

@DeddyH, mkinzler: Ich muss zugeben das ich die INI – Dateien immer im Programmverzeichnis mit abgelegt habe. Das hat auch Vor- und Nachteile, eine Arbeitskollege ist mal auf die „geniale“ Idee gekommen das Verzeichnis ‚Eigene Dateien’ von c:\ nach d:\ zu verschieben und hatte dann anschließend erhebliche Probleme.

Da verwechselst du etwas. Im "Eigene Dateien" Ordner speichert man keine Programmeinstellungen. Man speichert sie im Benutzerverzeichnis:

C:\Dokumente und Einstellungen\%user%\Anwendungsdaten\

oder im "ALL User Verzeichnis" - Anwendungsdaten.

[Chemiker]

Hallo bigg,

du hast Recht, habe ich Verwechselt. Habe jetzt schon den ganzen Tag gesucht und gelesen, Benutzerrecht bla bla, Vista bla bla usw.,
werde mal eine Pause einlegen.

Bis bald Chemiker

[Luckie]

Zitat:

Zitat von sakura

Zitat:

Zitat von Luckie

Ich würde Ini-Dateien wählen, da sie keine Baumstruktur erfordern und man für die Registry wieder einen Deinstaller mitliefern müsste.

Wenn die Ini-Dateien irgendwo in den UserApp-Daten liegt, dann ist da hoffentlich auch ein Deinstaller dabei, wer will schon, dass die HDD über Zeit mit solchen Müll zugestopft wird...

Das sieht Raymond Chen aber anders: What do I do with per-user data when I uninstall?.

[Hansa]

Wer ist Raymond Chen ? :shock: Egal, ich sehe das jedenfalls anders als der. :mrgreen: Soll etwas deinstalliert werden, dann muss auch alles weg, was VOR der Installation noch nicht da war. Wozu soll man da irgendwelchen Müll zurücklassen, den keiner mehr braucht ? Selbst wenn jemand was temporär deinstalliert, um es wieder neu zu installieren, seine Fenster wild verschoben hat und diese genauso wiederfinden möchte, dann soll er sich die INI in der das steht vorher sichern, deinstallieren/installieren und die gesicherte INI zurückkopieren und fertig. Jetzt kommen die M$-"Richtlinien" ins Spiel. Wo sollte die INI hin ? Bei mir liegt die genau in dem Odner, wo auch das Programm ist. Und das ist normalerweise einfach ein Verzeichnis. Erkläre mir mal einer, worin der Vorteil besteht, das Ganze in einem Ordner mit ellenlangem Namen zu speichern, den später eventuell keiner mehr findet. Von der Registry ganz zu schweigen. Anders siehts aus, sofern die Einstellungen Windows-benutzerdefiniert gespeichert werden sollen. Sollte dazu mal ein Bedarf entstehen, dann hätte ich immer noch eine INI beim Programm und in der wäre ein Bool-Eintrag, ob benutzerdefiniert gespeichert werden soll, oder nicht. Im ersten Fall würde ich dann im Benutzerverzeichnis speichern, im zweiten eben nicht. Ich brauche so keinen Deinstaller, weil zur Deinstallation einfach nur ein Ordner gelöscht werden muss.

Also : erkläre mir endlich mal einer den Sinn solcher Mickysoft-Vorgaben. Bei > 50 User siehts allerdings anders aus. Oder in sicherheitsrelevanten Bereichen. Aber auch da ist das Windows-Rechtesystem eher lächerlich und wird sowieso nicht richtig verwendet. Siehe Liechtenstein. :mrgreen:

[Luckie]

Zitat:

Zitat von Hansa

Aber auch da ist das Windows-Rechtesystem eher lächerlich und wird sowieso nicht richtig verwendet. Siehe Liechtenstein. :mrgreen:

Das Windows Rechtesystem ermöglicht wesentlich feinere Rechtevergaben als es unter Lunix möglich ist. Allerdings wird es dadurch auch wesentlich komplexer, so dass nicht alle Möglichkeiten ausgeschöpft werden. Und was Liechtenstein damit zu tun hat, verschließt sich mir irgendwie.

[Hansa]

Eben, es ist IMHO viel zu kompliziert, um praxisnah eingesetzt werden zu können. Warum soll man sich an solch praxisferne "Richtlinien" denn überhaupt halten. Z.B. beim Delphi-Styleguide ist das ganz anders. Da sind die Vorteile ganz klar zu erkennen und mit etwas Disziplin (oder auch Hilfsmitteln wie GExperts etc.) auch gut umzusetzen. Der Chemiker soll jedenfalls besser bei seinen INIs bleiben. Schließlich kann man die auch schnell mal editieren. Ich sehe darin einen Vorteil und keinen sicherheitskritischen Nachteil.

[Chemiker]

Hallo Luckie,

ich sehe das genauso wie sakura und Hansa, wenn das Programm deinstalliert wird sollte auch alles aufgeräumt werden. Also ich kann Raymond Chen auch nicht beipflichten. Also ich habe es noch nie erlebt, dass ich ein Programm deinstalliert habe, dass ich anschließend noch Daten von diesem Programm brauche die irgendwo in der Regitry oder als INI – Dateien im USER – Verzeichnis nicht mit deinstalliert wurden. Im Gegenteil, es ärgert mich wenn meine Festplatte mit irgendwelchen Müll vollgestopft wird, ich vermute Dir geht es genauso.

Zitat:

ermöglicht wesentlich feinere Rechtevergaben

in Linux bin ich jetzt nicht so der Profi, aber bei Windows hängt das doch sehr stark von der jeweiligen Windows – Version ab. Ich habe z.B. erhebliche Schwierigkeiten mit XP – Home, wenn ich versuche eine Komponente unter ein eingeschränktes Benutzerkonto zu installieren.

Unter XP – Pro ist dies natürlich möglich.

Bis bald Chemiker

[Hansa]

Chemiker, das Schlimme ist, es geht mit der Registry noch schlimmer. :mrgreen: Das Tha-XML Dingens kenne ich nicht, sieht allerdings wegen XML schon komplizierter aus als eine INI. Ein End-User hat durch XML keinerlei Vorteile, sofern aber sogar die Registry wegen Fensterpositionen etc. verwendet wird, hat er sogar Nachteile zu befürchten. Siehe die Ratschläge von Microsoft. Ja, wie Herr Chen empfiehlt, die Registry ruhig zuzumüllen. 8) Oder sowas :

habe mal bei mir geguckt in dem von Microsoft empfohlenen Verzeichnis. Wo steht da was ? Z.B. das hier :

C:\Dokumente und Einstellungen\User3\Anwendungsdaten\Free Download Manager\Update

Unter Vista sieht es zudem noch völlig anders aus. MS hat also für gewaltige Planungsunsicherheit gesorgt. Der User wird genötigt, vom Arbeitsplatz aus, mindestens 5 Schritte zu machen, um irgendeine Datei zu finden. Zuerst muss er das Laufwerk wissen und auswählen und dann noch 4 mal in ein Unterverzeichnis wechseln, um da dann endlich die richtige Datei suchen zu dürfen. Wenn solcher Schwachsinn auch noch propagiert wird, dann gute Nacht. Weitere Konsequenzen : wie soll man mit Registry, User-Verzeichnis usw. eine lauffähige CD-Demo-Version herstellen ? :shock: Eingriffe ins System (Registry, Abspeichern von Dateien an nicht klar definierten Orten usw.) ? Da spielen sogar DAUs wegen schlechter Erfahrungen mittlerweile nicht mehr mit. Die installieren im Zweifelsfall einfach nichts mehr !

[Chemiker]

Hallo Hansa,

Unter:

ThaXML-Library

ich habe das Tut. nur gelesen, kann also keine Aussage über die Qualität dieser Methode abgeben.


Bis bald Chemiker

[Hansa]

Nene, damit lockt mich keiner hinter dem Ofen hervor. :mrgreen: Klar, dass die INIs "nur" eindimensional sind. Aber ich brauche doch keine Baumstruktur, um irgendwelche Fensterkoordinaten zu speichern, oder feste Werte. Um dann noch dafür zu sorgen, dass wirklich alles bei Deinstallation weg ist ? Nochmals : wo liegt der Vorteil ? Wann / Wo / Wofür ist es nötig, tatsächlich für einzelne Benutzer separate Einstellungen zu speichern ? Wie gesagt, ist das notwendig, dann lasse ich mir ja noch ein benutzereigenes User-Verzeichnis gefallen. So etwa kann schon Sinn machen. Die Registry niemals ! Und XML ist für den Zweck IMHO auch überdimensioniert.

Wie hat sich negaH letzens geäüßert ? Er sei verknöchert oder wie ? :lol: Tja, vielleicht trifft das auf mich ja auch zu. Ich lasse die INI selber werkeln (zumindest für Fensterkoordinaten usw.).

Delphi-Quellcode:

procedure Tfrm.FormShow(Sender: TObject);
var FensterIni : TIniFile;
begin
  inherited;
  FensterIni := TIniFile.Create(FensterDateiName);
  try
    Left   := FensterIni.ReadInteger(Name,'Left',Left);
    Top    := FensterIni.ReadInteger(Name,'Top',Top);
    Width  := FensterIni.ReadInteger(Name,'Width',Width);
    Height := FensterIni.ReadInteger(Name,'Height',Height);
  finally
    FensterIni.Free;
  end;
end;

procedure Tfrm.FormClose(Sender: TObject; var Action: TCloseAction);
var FensterIni : TIniFile;
begin
  inherited;
  if not CDStart then begin
    FensterIni := TIniFile.Create(FensterDateiName);
    try
      FensterIni.WriteInteger(Name,'Left',Left);
      FensterIni.WriteInteger(Name,'Top',Top);
      FensterIni.WriteInteger(Name,'Width',Width);
      FensterIni.WriteInteger(Name,'Height',Height);
    finally
      FensterIni.Free;
    end;
  end;
  Action := caFree;
end;

Ausgeliefert wird das Programm mit einer Standardoberfläche. Werden an den Fensterkoordinaten Änderungen vorgenommen durch verschieben etc., dann werden sie direkt beim Schließen des Formulars gespeichert. Ab dann gelten diese. Und beim erneuten Öffnen eben neu ausgelesen. An der INI-Datei selber wird nichts geändert, die eventuellen Änderungen verwaltet sie selber. Hat sich jemand total verhauen, dann wird sie eben gelöscht und der fängt neu an. Man hätte allerdings immer noch den Ausweg, das einfach zu editieren. Wo die Datei liegt ist dem Programm dabei egal (kann auch User-Verzeichnis sein). Sofern tatsächlich jede Koordinate jedes Buttons/Labels usw. gespeichert werden müsste, dann wäre eine XML wohl doch etwas übersichtlicher. Eventuell könnte man allerdings auch verschiedene INIs zu Unterscheidung verwenden. Aber so etwas würde auch den Support quasi vernichten. Wie soll man denn dann jemand erklären, dass er mal sagen soll, was die Original-CheckBox rechts unten, die mittlerweile mitten im Form, steht anzeigt ? :shock: Betrachtet die User einfach als Kinder, die erst dann hören, wenn sie sich die Finger verbrannt haben. :mrgreen:

[Luckie]

Zitat:

Zitat von Hansa

Delphi-Quellcode:

procedure Tfrm.FormShow(Sender: TObject);

schlechte Idee, das im OnShow zu machen, da dieses Ereignis jedesmal beim Anzeigen aufgerufen wird. Dein Fenster wird also, wenn es verschoben ist, beim Anzeigen immer wieder auf die Startposition zurückspringen.

[Hansa]

Wieso soll da was zurückspringen ? :shock: Das caFree im OnClose sagt fast alles. Nämlich, dass die Forms nach dem Close weg sind. Vorher werden noch die dann aktuellen Koordinaten gespeichert. Sie werden zur Laufzeit erzeugt und angezeigt. Vorher guckt sie eben im OnShow zuerst noch in INI nach, wo sie zuletzt auf dem Bildschirm zu finden war. Sie kann also unmöglich wild in der Gegend rumspringen. :mrgreen:

[Luckie]

Zitat:

Das Ereignis OnShow wird ausgelöst, wenn das Formular angezeigt wird (d.h., wenn die Eigenschaft Visible des Formulars auf True gesetzt wird).

Da du in OnShow jedesmal die Koordinaten aus der Ini liest und setzt, wird das Fenster rumspringen, wenn die Eigenschaft Visible auf True gesetzt wird.

[xZise]

Zitat:

Zitat von Hansa

Wer ist Raymond Chen ? :shock: Egal, ich sehe das jedenfalls anders als der. :mrgreen: Soll etwas deinstalliert werden, dann muss auch alles weg, was VOR der Installation noch nicht da war. Wozu soll man da irgendwelchen Müll zurücklassen, den keiner mehr braucht ?[...]

Stimmt, nur sollte dem Benutzer die Entscheidung gegeben werden die Persönlichen Daten zu löschen (z.B. Speicherstände, Messergebnisse oder ähnliches).

Zitat:

Zitat von Hansa

[...]Wo sollte die INI hin ? Bei mir liegt die genau in dem Odner, wo auch das Programm ist. Und das ist normalerweise einfach ein Verzeichnis. Erkläre mir mal einer, worin der Vorteil besteht, das Ganze in einem Ordner mit ellenlangem Namen zu speichern, den später eventuell keiner mehr findet.[...]

Der Pfad ist ellenlang: "%appdata%" ?
Es ist guter Programmierstil es nicht im Programmverzeichnis zu schreiben, uns sehr guter Stil, wenn man es den Benutzter überlässt.

Und der Vorteil? Zum einem das die Datei Benutzerspezifisch ist und zum anderen und das ist viel wichtiger: Als normaler Windowsuser also nicht Admin, hat man, besonders bei installierten Programmen, unter Umständen keine schreibrechte auf den Ordner?
Sollte das Programm aber Schreibrechte benötigen wird es nicht benutzt. Besonders seit Vista wird glücklicherweise mehr zwischen User und Admin unterschieden.
Die einzigen Programme, die weiterhin benutzt werden obwohl sie das nicht (zu 100%) unterstützen sind Turbo Delphi (MainMenu-Editor) und SWAT 4. Ansonsten kenne ich keine Programme, die nicht wieder runtergeflogen sind.

Den Nachteil den du Anführst wird nichtig, wenn du die Entscheidung hast. Als Standardbenutzter (also schön mit allen möglichen Rechten) gönnst du dir dann das speichern im Programmordner. Diejenigen die von sich aus die Chance wahrnehmen und sie die Adminrechte entziehen, können dass dann weiterhin verwenden.
Und ansonsten gäbe es auch andere Möglichkeiten (ich habe z.B. A.D.C. programmiert) Benutzerspezifische Daten zu löschen.

Back to Topic:
Wenn du nur einfache eindimensionale Strukturen hast, sollte INI reichen. Ansonsten würde ich XML verwenden.
Also wenn du sowas speicherst:

• Breite
• Loginname
• Eigene Website

Da reicht INI vollkommen, sobald du aber diese Struktur verlässt, oder Aufzählungen hast, wäre XML möglicherweise besser.
Da ich nun gerne programmiere habe ich, um Schreibarbeit bei XML zu sparen, so etwas auf der Basis von INI gemacht.
Zum Beispiel hast du ein Adressbuch.
Ich würde dann folgendermaßen das machen:

Zitat:

[Adressbook]
Count=2
Entry[0].Name=John Doe
Entry[0].Adress.Street=Musterstrasse 123
Entry[0].Adress.Town=Musterort
Entry[1].Name=Jane Doe
Entry[1].Adress.Street=Musterstrasse 456
Entry[1].Adress.Town=Musterort

Die Registry würde ich generell meiden.

MfG
xZise

[Hansa]

@Luckie ; was zum Teufel springt denn da rum ? :shock: Siehe Anhang. Der Ini-Code von weiter oben steckt da drin.

[Luckie]

Zitat:

---------------------------
Project1
---------------------------
In FENSTER.INI kann nicht geschrieben werden.
---------------------------
OK
---------------------------

Und jetzt?

[Hansa]

Tja, da sieht mans. :zwinker: Halte dich gefälligst an die MS-Regeln. :mrgreen:

[Luckie]

Ich denke eher du solltest dich an die MS Regeln halten. Desweiteren hab eich im Dowloadverzeichnis Schreibrechte und an welche Regeln halte ich mich da nicht?

[xZise]

BOAR was is'n das fürn Stil xD
Programme die man mit'm Taskmgr abschießen muss :shock:

MfG
xZise

[Hansa]

Vorab : Das hier soll kein MS-Bashing werden ! Muss das mal klarstellen, weil das eventuell so aussieht. Zumindest von meiner Seite aus ist M$ eher zweitrangig. Aber die sollen praktikable Lösungen anbieten und nicht irgendwelche theoretischen Vorschriften ! Das würde ich auch Bill Gates so sagen.

Mir ist abweichend von der Hauptfrage aber noch folgendes aufgefallen : die EXE im Anhang oben geht schon so. Da springt nichts. Allerdings kommt tatsächlich der von Luckie gemeldete Fehler. Da fehlen offensichtlich Schreibrechte. Ich wollte der Sache deshalb jetzt mal etwas auf den Grund gehen. Also : Admin legt User "Test" neu an (beim Admin geht sowieso alles) -> die EXE wird in %homepath% kopiert (die von User "Test"). Admin meldet sich ab und User Test wird neu angemeldet. Hat aber ansch. auch keine Schreibrechte (Fehler bleibt wie gehabt). Zumindest dieselbe Fehlermeldung. Abhilfe wäre jetzt das, was fast jeder sowieso macht : User=Admin. Wozu dann aber überhaupt Rechte/User ? Dann habe ich mir die Rechte des Users "Test" angesehen und stelle fest : es gibt nur Admins und User mit beschränkten Rechten zur Auswahl (XPpro SP2). Das war doch früher anders oder nicht ? :shock: Habe in Benutzerkonten, Freigaben, Verwaltung usw. nichts gefunden. Wo vergebe ich denn jetzt Rechte für genau benannte Verzeichnisse ? Ich muss doch dem User "Test" ein Verzeichnis zuordnen können, wo er was abspeichern kann.


Zu guter Letzt noch das hier :

Zitat:

Zitat von xZise

BOAR was is'n das fürn Stil xD

Das frage ich mich in der Tat auch. Ist jemand, der einen solchen Schreibstil hat, überhaupt in der Lage zu programmieren ? :mrgreen:

Und das :

Zitat:

Zitat von xZise

Programme die man mit'm Taskmgr abschießen muss :shock: ...

Tatsache ist, es soll ein Fenster geschlossen werden, welches Fehler anzeigt und der DAU erkennt nicht, dass nicht das fehlerverursachende Fenster geschlossen werden muss, sondern das Programm an sich, um weiterzukommen. Siehe Kontext. Genau das ist übersehen worden und deshalb kommt die Brechstange. 8) Ein Delphi Programmierer, der den Quelltext der fehlerverursachenden Stelle vor sich hat, der hätte anhand von "Form1" bzw. "Form2" gemerkt, dass der Taskmanager für solchen Kleinkram überflüssig ist. Dürfte allerdings zuviel verlangt sein.

[mkinzler]

Zitat:

Zumindest dieselbe Fehlermeldung. Abhilfe wäre jetzt das, was fast jeder sowieso macht : User=Admin. Wozu dann aber überhaupt Rechte/User ?

Man könnte den Besitzer des Verzeichnisses auch auf den gewünschten Benutzer setzten bzw. ihm Schreibrechte darauf gewähren.

Zitat:

Dann habe ich mir die Rechte des Users "Test" angesehen und stelle fest : es gibt nur Admins und User mit beschränkten Rechten zur Auswahl (XPpro SP2). Das war doch früher anders oder nicht ?

ist auch in XP SP2 so.

Zitat:

Wo vergebe ich denn jetzt Rechte für genau benannte Verzeichnisse ? Ich muss doch dem User "Test" ein Verzeichnis zuordnen können, wo er was abspeichern kann.

Im Kontextmenü unter Eigenschaften->Sicherheit bzw. Eigenschaften->Sicherheit->erweitert->Besitzer.

[Luckie]

@hansa: Und wo will dein Programm die Ini-Datei abspeichern? Im Programmverzeichnis wohl nicht, denn da habe ich Schreibrechte, da es in diesem Fall das Downloadverzeichnis war.

[xZise]

Zitat:

Zitat von Luckie

@hansa: Und wo will dein Programm die Ini-Datei abspeichern? Im Programmverzeichnis wohl nicht, denn da habe ich Schreibrechte, da es in diesem Fall das Downloadverzeichnis war.

Willst du es wirklich wissen?
Ich habe es unter Ubuntu mit Wine mal ausgeführt, und ich habe dann wie verrückt gesucht (nagut ... es sind ja nicht so viele Dateien, aber gesucht habe ich schon):
Zuerst unter "C:\": Nichts
Dann Dok. und Einst.: Auch nichts
Und dann auf "C:\Programme": Auch nichts
Und dann blieb nur ein Ordner übrig:
"C:\Windows" und was sehe ich da: "FENSTER.INI"

Ich habe mal ein Screen angehangen.

Zitat:

Zitat von Hansa

[...]Mir ist abweichend von der Hauptfrage aber noch folgendes aufgefallen : die EXE im Anhang oben geht schon so. Da springt nichts.[...]

Wahrscheinlich hat Luckie dass mit OnActivate verwechselt, oder du hast ihn falsch verstanden (minimierten und wiederherstellen).

Zitat:

Zitat von Hansa

Allerdings kommt tatsächlich der von Luckie gemeldete Fehler. Da fehlen offensichtlich Schreibrechte. Ich wollte der Sache deshalb jetzt mal etwas auf den Grund gehen. Also : Admin legt User "Test" neu an (beim Admin geht sowieso alles) -> die EXE wird in %homepath% kopiert (die von User "Test"). Admin meldet sich ab und User Test wird neu angemeldet. Hat aber ansch. auch keine Schreibrechte (Fehler bleibt wie gehabt). Zumindest dieselbe Fehlermeldung. Abhilfe wäre jetzt das, was fast jeder sowieso macht : User=Admin. Wozu dann aber überhaupt Rechte/User ? Dann habe ich mir die Rechte des Users "Test" angesehen und stelle fest : es gibt nur Admins und User mit beschränkten Rechten zur Auswahl (XPpro SP2). Das war doch früher anders oder nicht ? :shock: Habe in Benutzerkonten, Freigaben, Verwaltung usw. nichts gefunden. Wo vergebe ich denn jetzt Rechte für genau benannte Verzeichnisse ? Ich muss doch dem User "Test" ein Verzeichnis zuordnen können, wo er was abspeichern kann.

Das machst du andersherum: Du sagst nicht dem Benutzter welche Ordner er benutzten kann, sondern du sagst den Ordnern welche Benutzer den Ordner benutzten dürfen.

Zitat:

Zitat von Hansa

Zitat:

Zitat von xZise

BOAR was is'n das fürn Stil xD

Das frage ich mich in der Tat auch. Ist jemand, der einen solchen Schreibstil hat, überhaupt in der Lage zu programmieren ? :mrgreen:

Naja ^^ Muttersprache: Delphi

Zitat:

Zitat von Hansa

Und das :

Zitat:

Zitat von xZise

Programme die man mit'm Taskmgr abschießen muss :shock: ...

Tatsache ist, es soll ein Fenster geschlossen werden, welches Fehler anzeigt und der DAU erkennt nicht, dass nicht das fehlerverursachende Fenster geschlossen werden muss, sondern das Programm an sich, um weiterzukommen. Siehe Kontext. Genau das ist übersehen worden und deshalb kommt die Brechstange.

Naja normalerweise begegnet man "ShowModal" Fenstern.

Zitat:

Zitat von Hansa

[...] 8) Ein Delphi Programmierer, der den Quelltext der fehlerverursachenden Stelle vor sich hat, der hätte anhand von "Form1" bzw. "Form2" gemerkt, dass der Taskmanager für solchen Kleinkram überflüssig ist. Dürfte allerdings zuviel verlangt sein.

-> Delphi Programmierer ==> Stimmt
-> Quellcode ==> Negativ
==> Bedingung nicht erfüllt

MfG
xZise

[Chemiker]

Hallo,

@Luckie:
Im Forum der Delphi-Treff wird einem Tut. über INI – Dateien auch Form.Show angegeben siehe:

tutorial


@Hansa:
Ich habe mich seinerzeit an das Beispiel in der Delphi – Hilfe orientiert. In diesem Beispiel wurden die INI – Datei in Form.Create aufgerufen. Rein gefühlsmäßig finde ich diese Variante auch charmanter. Ob das Fenster beim Neuzeichnen die INI – Datei wieder ausliest werde ich mal testen.

@zZise:
Es geht Hansa darum die Datei zu finden und dann kann er schon ziemlich lang werden, keine Frage.

@mkinzler:
Das funktioniert aber nicht mit XP – Home. Wie es bei Vista geregelt ist, kann ich nicht sagen, da ich kein Rechner mit Vista besitze.

@Hansa, @zZise:

Bitte keine persönliche Animositäten, das bringt hier keinen weiter. Meinungen vertreten ist o.k..

Vielleicht könnte man die ganze Informationen mal in ein Tut. einarbeiten und die Vor- und Nachteile ausarbeiten. Ich könnte mir vorstellen, dass das für andere Forum – Besucher ganz informativ wäre.

Bis bald Chemiker

[mkinzler]

Kann man aber (teilweise) nachrüsten
http://www.fajo.de/portal/index.php?...w&id=6&Itemid=

[xZise]

Zitat:

Zitat von Chemiker

[...]@zZise:
Es geht Hansa darum die Datei zu finden und dann kann er schon ziemlich lang werden, keine Frage.
[...]

Ich würde aber lieber etwas längeren Code haben, als ein Programm das nicht läuft ;)

Abgesehen davon, dass es dann auch professioneller wirkt :)

Ganz einfach wäre das:

Delphi-Quellcode:

APath := GetEnvironmentVariable('appdata') + '\MEINORDNER';
APath := ExtractFilePath(ParamStr(0)) + 'MEINORDNER';

So gravierend länger wird es nicht ;)
Mit Luckies "GetShellFolder" (so hieß die doch?) kannst du sogar noch ein paar Zeichen raushauen ;)

ich würde an deiner Stelle einfach das folgendermaßen machen:

• Du erstellst dir ein Dialog mit zwei Radiobuttons: Einmal Appdata benutzten und einmal Programmordner benutzen
• Im Projektcode rufst du diese Form ganz am Anfang auf
• Der Dialog speichert im Programmordner eine Datei in der steht, wo die eigentlichen Einstellungen sind (also einmal als Admin ausführen)
• Im FormCreate ließt du diese Datei aus, und setzt dann eine string Variable in der nachher der Einstellungenordner ist.

MfG
xZise