Registry-Probleme unter Vista

[Popov]

Moment, ich hab dich so eben drauf hingewiesen, daß du dich unprofessionell benommen hast und das ist deine Antwort?

[wido]

Zitat von Popov:

Ich will nichts sagen, aber das sind unqualifizierte Äußerungen. Ich gestehe dir durchaus zu keine Enterprise Version haben zu müssen, so daß du den Code dir nicht angucken kannst, aber wenn du eine Version hast, dann hätte ich nach so langer Diskussion mir den Code schon längst angeguckt. Dann wüßtest du, daß das was du sagst nicht stimmt.

Mach mal folgendes:
Schreib Dir ein kleines tool wie ich, daß deine Unit verwendet und in dem einfach nur folgendes steht:

EraseIniSection('Software'); Dann verbietest Du Dir selbst einfach mal den Schreibzugriff auf den Registry Key in den Du schreiben willst ('HKCU\Software\Project1' z.B.) und startest Dein Programm. Nachdem Du Dein Userprofil danach gelöscht und neu erstellt hast weil der kleine Befehl es komplett unbrauchbar gemacht hat, darfst Du mir gerne nochmal erzählen, daß ich Unrecht habe . Siehe dazu auch das geloggte Experiment auf meinem Testrechner im Attachment .

[Daniel]

Meine Herren,

bitte zurück zum Thema. Ob die Klasse "TRegIniFile" unter Vista unter allen Umständen wie die Original-Klasse TRegistry funktioniert, müsste ein detaillierter Test klären. Fakt ist, dass man unter Vista doppelt und dreifach aufpassen muss, nicht in die Restriktionen des User-Accounts zu laufen.

[DeddyH]

Hallo Cheffe, eben darum sollte es ja ursprünglich gehen (wenn ich die ersten Ansätze der anderen zur Fehlersuche richtig interpretiert habe). Fakt ist ja nun mal, dass TRegIniFile die Rückgabewerte seines Vorfahren nicht prüft und stattdessen optimistisch in die Zukunft sieht. Wenn das OpenKey im Konstruktor von TRegIniFile schon nicht tut, wie soll dann weiter verfahren werden? Nun wollten wir vorsichtig andeuten, stattdessen vielleicht lieber auf TRegistry zurückzugreifen, da man auf diese Weise prüfen kann, wo es denn nun wirklich hakt. Wie das geendet hat, kann man ja nachlesen.

[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.

[edit]
@DeddyH: Habe Deine Antwort zu spät gelesen ... die rote Box ist gerade im Testforum
[/edit]

[DeddyH]

[OT]

Zitat von Daniel:

... die rote Box ist gerade im Testforum

Da ist meine ständig [/OT]

[Luckie]

Zitat von Daniel:

Ob die Klasse "TRegIniFile" unter Vista unter allen Umständen wie die Original-Klasse TRegistry funktioniert, müsste ein detaillierter Test klären.

Genau das versuchen wir Popov seit dem ersten Posting klar zu machen. Aber er weigert sich ja beharrlich eine Alternative in betracht zu ziehen.

Zitat von Popov:

Zitat von Luckie:

Genau das ist doch das Problem. Benutze TRegistry damit du endlich mal einen Fehler ls Feedback bekommst.

Luckie, das nötige Feedback habe ich schon.

Ich meine nicht das Feedback von deinen Kunden, sondern ein Feedback von Windows in Form einer Fehlermeldung! Aber so lange du auf dieser komischen TregistryIni-Klasse beharrst, wirst du das nie bekommen.

Zitat:

Der Code in meiner Unit entfällt keine Fehler.

Selbst Borland ist nicht unfehlbar. Menschen machen Fehler, das liegt in ihrer Natur.

Zitat:

Der Programmpfad zu wenige Rechte? Möglich, aber dann bringt mir OpenKey auch keine bessere Info.

Doch, denn dann würde GetLastError Fehlercode 5 ("Zugriff verweigert") zurückgeben und du wüsstest, warum es nicht funktioniert.

Zitat:

Ich schätze, daß du einfach die TRegIniFile nicht kennst

Was gibt es da zu kennen? Ich habe es nie benutzt, eben weil es nur da ist aus Kompatibilitätsgründen zu Windows 3.1x.

Zitat:

Zitat:

Wird also mal zeit endlich die Unit mal zu überarbeiten.

Besteht keine Notwendigkeit.

Dann ist dir nicht zu helfen. So lang du darauf bestehst, dass dein und Borlands Code fehlerfrei sind und nicht mal ansatzweise bereit bist etwas auszuprobieren, ist es sinnlos hier weiter zu diskutieren und dir helfen zu wollen.

Zitat:

Zitat:

Doch das besagt, dass TRegIni versucht so zu arbeiten wie unter 16-Bit Windows 3.1x. Und das ist schon mehr als veraltet. Vista unterstützt keine 16-Bit Programme mehr (in wiefern das hier eine Rolle spielt, weiß ich nicht).

Diesen Kommentar hätte ich von sonstwem erwartet, aber nicht von dir. TRegIniFile wird von TRegistry abgeleitet. Wo siehst du da 16 Bit? Wo besteht das Problem sich vor so einem Kommetar den Quellcode der TRegIniFile anzugucken? Dann würde man eventuell andere Kommentare abgeben.

Dr Code ist natürlich 32-Bit, aber er versucht zu arbeiten wie unter Windows 16-Bit.

Zitat:

Es ist eigentlich schlimm, denn die Kommentare zeigen, daß man etwas sagt was üblich ist, aber sich nicht mit dem Problem beschäftigt.

Nein schlimm ist, dass du absolut resistent gegen irgendwelche Vorschläge von uns bist. Ich frage mich lansam, ob du überhaupt Hilfe willst.

[Luckie]

Zitat von Daniel:

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:

Das sagen wir seit vier Seiten Postings.

[Daniel]

Zitat von Luckie:

Das sagen wir seit vier Seiten Postings.

... schon, aber es war mir wichtig und ... außerdem bin ich Admin. *g*



Davon mal abgesehen, funktioniert die Demo-Anwendung bei mir unter Windows Vista. Und das ohne besondere Rechte.

[Daniel]

Eine Kleinigkeit noch:

Mischaeeeeel hat geschrieben:

Der Code ist natürlich 32-Bit, aber er versucht zu arbeiten wie unter Windows 16-Bit.

So weit würde ich nicht gehen. Die Klasse "TRegIniFile" imitiert die Schnittstellen der guten, alten INI-Datei. Intern werkelt aber ein vollständiges und aktuelles Objekt der Klasse "TRegistry". An der tatsächlich verrichteten Arbeit ist nichts auszusetzen, nur sind die Möglichkeiten, auf diesen Vorgang einzuwirken, viel zu gering. Das Beginnt bei der expliziten Wahl der Zugriffsrechte und gipfelt eben - wie in diesem Fall - an der Fehlerbehandlung, die in einem "geht" bzw. "geht nicht" mündet.

Das soll kein Plädoyer für die Verwendung dieser Klasse sein, aber als Übergangslösung war sie damals - Ende der 90er - durchaus geeignet. Nur ist sie eben mittlerweile von der Realität überholt worden.