Zitat von
Daniel:
Ich habe mir mal eben das Demo-Programm abgesehen und dabei einen Blick auf die Klasse "TRegIniFile" geworfen. Ich halte diese Klasse für problematisch, weil sie eben nicht dediziert prüft, wo was falsch gelaufen ist und dies an die Anwendung zurückliefert.
Für die Fehlersuche ist eine direkte Verwendung der Klasse TRegistry geeigneter, da man hier Operation für Operation auf Ihren Erfolg hin prüfen kann:
TRegistry.Create
TRegistry.RootKey = _XY_
KeyExists
CreateKey
OpenKey
Read_XYZ_
Write_XYZ_
CloseKey
Danach ist unmittelbar klar, wo es beim Anwender knallt und oftmals ergibt sich dann aus der Situation auch direkt die Ursache für das Fehlverhalten.
Hallo Daniel, deine Ausführungen sind zum Teil richtig, zum Teil leider unrichtig.
Du, wie zum Teil die anderen, sehen die TRegIniFile im ganzen Zusammenhang der Registry und dann sagt ihr euch, daß sie zu wenig Möglichkeiten liefert. Das ist nicht richtig, denn die TRegIniFile arbeitet nur in dem Bereich
HKCU/Software. Würde ich mit TRegIniFile versuchen auf die ganze Registry zugreifen zu wollen, du hättest dann Recht, denn dann könnte man über zu wenig Möglichkeiten sprechen. Es ist ja nicht so als ob ich nur die TRegIniFile nutze. Im Schnitt nutze ich die TRegistry wohl öfters wenn ich allgemein mit der Registry arbeite, aber hier geht es nur um den einen Pfad. Und das besondere an dem Pfad ist, daß man hier wiederum einiges an möglichen Fehlern ausschließen kann. Und es ist das was ich versuche klar zu machen.
Die
HKCU/Software ist in der Regel nicht schreibgeschützt, bzw. in Rechten eingeschränkt. Man hat dort die Möglichkeiten die Rechte einzuschränken, weil es ein Teil der Registry ist und man für die
HKCU keine Sonderregeln erst5ellen wollte, aber die
HKCU/Software hat keinerlei Bereiche mit geringeren Rechten. Ist ja auch unnötig, da die
HKCU abhängig vom Konto ist. Jedes Konto hat seine eigene
HKCU. Wechsele ich das Konto, habe ich eine andere
HKCU. CU bedeutet Current User. Das sage ich so deutlich, denn das muß man sich erst bewust machen. Die
HKCU/Software ist also nicht in Rechten eingeschränkt wie andere Teile der Registry. Bei den anderen Teilen der Registry kann einem doch tatsächlich passieren, daß man zwar lesen kann, aber nicht schreiben, oder, daß man garnichts darf. Bei der
HKCU/Software kann es das nur theoretisch passieren. Somit entfällt die Notwendigkeit Fehler abzufangen, denn es kann keine Fehler geben. Fehler kann es nur geben wenn die Festplatte voll ist. Aber dann ist es wohl das kleinste Problem und völlig uninteressant ob die Einstellungen nicht gespeichert werden konnten. Die zweite Fehlermöglichkeit ist auch nur eher theoretisch. Theoretisch kann man den Pfad in Rechten einschränken. Aber wer tut das? Wozu? Da jedes Konto eine eigene
HKCU hat, kann kein anderes Konto Zugriff auf den Teil der Registry erlangen. Rechteverwaltung ist also unnötig. Ich kann ALLEN die Rechte nehmen, selbst den Admins, und die werden nie Probleme haben, denn ein Admin wird nie deswegen Problem haben, denn er er hat überhaupt keine Möglichkeit auf diese
HKCU zuzugreifen.
Die
HKCU/Software hat einen gewissen Sonderstatus gegenüber den anderen Teilen der registry, denn dieser Bereich ist ein von Microsoft garantierter Bereich. Auf diesen Bereich kann man immer zugreifen und wird nie Probleme bekommen. Die Probleme sind nur theoretisch. Wozu soll ich also irgendwo auf Fehlersuche gehen wo es überhaupt keine Fehler geben kann? Ich bin ein wenig gespalten über die Herren die hier meinen mich aufklären zu müssen, denn anscheinend haben die keine Ahnung über diesen Teil der Registry. Eigentlich müßte ich erschrocken sein. Wenn die keine Ahnung von der
HKCU/Software haben, dann kann man annehmen, daß sie ihre Einstellungen an jeden Teil der Registry schreiben. Und wenn sie sie in
HKCU/Software schreiben, dann nur zufällig, weil sie vielleicht gehört haben, daß auch die anderen es so machen. Dabei kann es bei der
HKCU/Software unter üblichen Umständen keine Fehler geben.
Nun betrachten wir mit diesem Wissen die TRegIniFile noch einmal. Die TRegIniFile hat keine Fehlerabfragen, weil es nicht geplannt ist, daß es Fehler gibt. Noch ein malfür alle die es nicht verstanden haben: im Gegensatz zu anderen bereichen der Registry hat man auf
HKCU/Software immer Zugriff. Dieser Bereich soll die INIs ersetzten, er sollte den Windowsordenr entlasten, also hat Microsoft dem Konto volle und uneingeschränkte Rechte über diesen Teil der Registry gegeben. Wieso wissen es die Leute, die Programmierer, die hier meckern das nicht? Ich möchte mal einen sehen der unter normalen Umständen, d.h. ohne die Registry manipuliert zu haben, in diesem Bereich Probleme hatten. Gibt es nicht.
Also Daniel, wie du siehst stellt sich die Frage nach mehr Möglichkeiten der TRegistry garnicht. Wer in
HKCU/Software mit TRegisry arbeitet und Fehler abfrag, der hat keine Ahnung was er da macht. Und da ich bei TRegIniFile mit Create und Free alles korrekt einleite und freigeben, besteht auch hier kein Grund zu Sorge.
Letztendlich kann man TRegIniFile nur die wenig Möglichkeiten vorwerfen, d.h. sie kann letztendlich nur Strings speichern und lesen, aber das ist ein anderes Thema und wenn ich was anderes brauch, dann werde ich es schon nehmen.
Ich hoffe jetzt einige aufgeklärt zu haben. Bevor man etwas kritisiert, sollte man es kennen. Das ist wie mit den Auto und dem Fallschirm. Im Auto brauche ich nun mal keinen Fallschirm, auch wenn theoretisch die Möglichkeit besteht, daß ich mal über eine Schlucht stürze. Das gleiche ist auch mit TRegIniFile. Es besteht die theoretische Möglichkeit, daß die Festplatte voll ist und dann kriege ich keine Fehlermeldung. Aber genau sowenig wie ich bei Autofahren einen Fallschirm brauche, brauche ich bei TRegIniFile eine Fehlermeldung.
Ich hoffe, daß es jetzt keine Unklarheiten mehr gibt. Ansonsten bin ich für Rückfragen gerne bereit. Und für alle Profis die sich jetzt in der Ehere gekränkt fühlen: man kann nicht alles wissen. Es gibt auch Bereiche wo ich keine Ahnung habe.