registry-exporte (*.reg) einlesen?

[DGL-luke]

ich habe die aufgabenstellung, registryexporte sowohl selbst zu machen als auch vernünftig, z.b. in eine treeview, einzulesen.

da weder tregistry noch treginifile vernünftige exportmethoden haben, seh ich mir gerade die struktur von *.reg-exporten an. die is ja eigentlich klar - aber es ist eine heidenarbeit, so etwas in eine treeview einzulesen, da ja die unterstrukturen einzeln rumliegen.

deshalb zwei fragen:

1. gibt es bereits eine komponente, die so etwas kann? gerne auch direkt aus der registry lesen, nur im- und export sollte halt möglich sein. und zwar import auch so, dass es nicht nur direkt in die registry, sondern erst einmal in einen tree kommen kann.

2. gibt es eine gute möglichkeit, in eine treeview direkt den pfad 'X\Y\Z' einzulesen, ohne erst x,y,z herausparsen und einzeln eintragen zu müssen? ich muss ja auch noch überprüfen, ob ich einen neuen zweig anlegen oder in einen bereits vorhandenen schreiben muss.

[DGL-luke]

*push*

niemand ne idee? ich kann ja auch selber was machen, aber wenns schon was gibt, wäre das ja schön zu haben.....

[Phistev]

Vergleich mal eine INI-Datei mit einer REG-Datei

Damit hättest du die Schlüsselnamen von den Werten getrennt.

[DGL-luke]

richtig. sehr richtig, phistev. Note fünf wegen themaverfehlung

das is mir klar, aber ich krieg da ja die strukturen immer einzeln. was ja auch klar ist. sprich eine struktur HKEY_LOCAL_MACHINE\STH und einmal HKEY_LOCAL_MACHINE\STH\ONEMORE und dann noch HKEY_LOCAL_MACHINE\STH\TWO usw. usf. und die muss ich halt jetzt einzeln in ein tree ähnliches gebilde kriegen. sprich, ich hab den vollen pfad, und muss den auf einen relativen pfad abbilden oder so.
und wie oben gesagt:

Zitat:

[...]in eine treeview direkt den pfad 'X\Y\Z' einzulesen, ohne erst x,y,z herausparsen und einzeln eintragen zu müssen? ich muss ja auch noch überprüfen, ob ich einen neuen zweig anlegen oder in einen bereits vorhandenen schreiben muss.

somit brauche ich eben etwas, das mir diese arbeit abnimmt, also sowas wie "function regToTreeView(reg:TInifile):TTreeNodes;", oder ich muss es mir selber coden. was aber wohl extrem fuzzelig wird, mit nem haufen parsen und in den sections rumwühlen und in den values rumwühlen....

[marabu]

Hallo Lukas,

Zitat von DGL-luke:

was aber wohl extrem fuzzelig wird, mit nem haufen parsen und in den sections rumwühlen und in den values rumwühlen....

schade das ich das nicht sehen kann...

Du wirst nämlich wühlen müssen - fürchte ich. Allerdings kann ich nicht sehen, dass du schrecklich tief wühlen müsstest - um beim Bild zu bleiben.

Grüße vom marabu

[DGL-luke]

tief nicht, aber ausdauernd... na gut... ich komm dann in zwei jahren wieder wenn ichs geschafft hab *seufz*

[scp]

Bei Torry gibt es einen TNRegView, der zeigt die Registry als Treeview an. Anders als bei Torry angegeben: Der Sourcecode liegt bei.
Anhand dieses Beispiels wirst du sicherlich auch die Darstellung einer .reg-Datei hinbekommen.

PS: Ich weis nicht, ob TIniFile mit den .reg-Dateien von 2000/XP umgehen kann, da dies Unicode-Dateien sind, ansonsten benutzt du halt TWideStringList.

[DGL-luke]

das könnte die Uber-Lösung sein.

muss jetzt mal off, aber wenn das ding tut, was es verspricht, kriegst du ein ganz fettes karma von mir!

[mh166]

Zitat von DGL-luke:

ich komm dann in zwei jahren wieder wenn ichs geschafft hab

Ich bin nicht der Meinung, dass das Ganze so ein großes Problem sein wird... Hier mal mein Lösungsansatz (auch wenns mit parsen ist, aber anders wirds wohl nich gehen... Auch ne Kompo kann das nich anders):

Zitat von Test.reg:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\_Just Some Test!]
@="Standard-Wert"
"REG_SZ - Zeichenfolge"="REG_SZ - Zeichenfolge"
"REG_BINARY - Binär"=hex:ff,1a,b4,d6,23
"REG_DWORD - DWORD"=dword:23000005
"REG_MULTI_SZ - Wert der mehrteiligen Zeichenfolge"=hex(7):44,00,61,00,73,00,\
20,00,69,00,73,00,74,00,20,00,65,00,69,00,6e,00,65 ,00,20,00,5a,00,65,00,69,\
00,6c,00,65,00,21,00,00,00,55,00,6e,00,64,00,20,00 ,64,00,69,00,65,00,20,00,\
7a,00,77,00,65,00,69,00,74,00,65,00,21,00,00,00,55 ,00,6e,00,64,00,20,00,68,\
00,69,00,65,00,72,00,20,00,65,00,69,00,6e,00,65,00 ,20,00,64,00,72,00,69,00,\
74,00,74,00,65,00,2e,00,2e,00,2e,00,00,00,2e,00,2e ,00,2e,00,73,00,6f,00,77,\
00,69,00,65,00,20,00,65,00,69,00,6e,00,65,00,20,00 ,76,00,69,00,65,00,72,00,\
74,00,65,00,20,00,5a,00,65,00,69,00,6c,00,65,00,2e ,00,00,00,53,00,63,00,68,\
00,6c,00,75,00,73,00,73,00,20,00,6a,00,65,00,74,00 ,7a,00,74,00,2c,00,20,00,\
67,00,65,00,6e,00,75,00,67,00,20,00,67,00,65,00,74 ,00,65,00,73,00,74,00,65,\
00,74,00,21,00,00,00,00,00
"REG_EXPAND_SZ - Wert der erweiterbaren Zeichenfolge"=hex(2):41,00,6c,00,73,00,\
6f,00,20,00,77,00,61,00,73,00,20,00,64,00,65,00,72 ,00,20,00,55,00,6e,00,74,\
00,65,00,72,00,73,00,63,00,68,00,69,00,65,00,64,00 ,20,00,7a,00,77,00,69,00,\
73,00,63,00,68,00,65,00,6e,00,20,00,52,00,45,00,47 ,00,5f,00,45,00,58,00,50,\
00,41,00,4e,00,44,00,5f,00,53,00,5a,00,20,00,75,00 ,6e,00,64,00,20,00,6e,00,\
75,00,72,00,20,00,52,00,45,00,47,00,5f,00,53,00,5a ,00,20,00,69,00,73,00,74,\
00,2e,00,2e,00,2e,00,20,00,49,00,63,00,68,00,20,00 ,77,00,65,00,69,00,df,00,\
20,00,65,00,73,00,20,00,6e,00,69,00,63,00,68,00,74 ,00,2e,00,20,00,57,00,61,\
00,68,00,72,00,73,00,63,00,68,00,65,00,69,00,6e,00 ,6c,00,69,00,63,00,68,00,\
20,00,6e,00,75,00,72,00,20,00,64,00,69,00,65,00,20 ,00,4c,00,e4,00,6e,00,67,\
00,65,00,2e,00,20,00,4e,00,61,00,6a,00,61,00,2c,00 ,20,00,64,00,61,00,73,00,\
20,00,73,00,6f,00,6c,00,6c,00,20,00,6a,00,61,00,20 ,00,61,00,75,00,63,00,68,\
00,20,00,6e,00,75,00,72,00,20,00,6e,00,65,00,20,00 ,44,00,65,00,6d,00,6f,00,\
20,00,73,00,65,00,69,00,6e,00,21,00,00,00

[HKEY_CURRENT_USER\Software\_Just Some Test!\Another Subkey]

So, dass ist mal ein Test, in dem ich alle REG_*-Arten verwendet habe. Man sieht, dass das Prinup immer gleich ist:
Die Datei beginnt mit der Versionsangabe des Reg-Edits. Für alle Fälle kannste ja auch alle Zeilen bis zum ersten '[' wegschnippeln oder in nem zusätzlichen Info-Memo anzeigen lassen.

Der "Pfad" zum Schlüssel wird als INI-Section gespeichert. D.h. du brauchst nur die Sections raussuchen und diese dann am '\' trennen, um den nächsten Unterschlüssel zu bekommen. Das kannst du dann in ein dynamisches Array speichern und das dann der Reihe nach durchlaufen. Existiert der gewünschte Schlüssel, dann wird der entsprechende TTreeNode temporär gespeichert und man guckt nach dem nächsten. Existiert ein Schlüssel noch nicht, so wird ein entsprechender TTreeNode erzeugt. Dabei fällt mir auf, dass man das vielleicht besser per Rekursion lösen könnte, anstatt mit Schleife und dyn. Array. Obwohl es sich hier nicht viel nehmen sollte, denke ich.

Und zu den Werten: Das '@' steht immer für den Standardwert. Ansonsten stehen alle Schlüsselnamen in Anführungszeichen. Danach kommt das '='. Steht nun ein '"', so ist es ein normaler String. Steht da DWORD, so ist es ein selbiger. steht da 'hex:', dann ist es ein Hexadezimalwert. Steht 'hex(7):', dann ist es ein Multiline-String (stichwort TMemo) und bei 'hex(2):' diese Extended-Zeichenkette (ich vermute mal, die lässt einfach größere Längen zu, als das "normale" REG_SZ). Wichtig ist bei den Hexen, dass die durch Komma getrennt sind und am Ende der Zeile ein ',\' steht.

So, daraus sollte sich eigentlich (mehr oder weniger) einfach was zusammenschneidern lassen. Ich denke n bisschen Tipparbeit wirste bei den Hex-Zeugs haben, aber ansonsten gehts scho, denn im Prinzip is das doch alles bloß Str_Replace-Arbeit.

mfg, mh166

[DGL-luke]

nein, du verstehst das nicht ganz! Das Format ist mir absolut klar! aber ich muss so vorgehen:

erstmal sections = pfade holen (geht ja relativ einfach, mit den Inidatei)

jetzt habe ich hundert strings, die so aufgebaut sind: A\B,A\B\C,A\B\C\D....
also nehm ich den ersten string, und erstelle in meiner treeview Überknoten->A->B
jetzt komt der nächste dran: erst auseinanderbauen, so dass ich ('A','B','C')(=stringlist) bekomme.
schauen: gibt es A schon? wenn ja, node:=A; wenn nein: node:=treeview.add(node,'A'), wobei auf den überknoten zeigte, und jetzt auf A zeigt.
jetzt schaue ich, ob ich weiter verzweigen muss. ja, muss ich, die stringlist geht noch weiter. also schauen: gibt es A->B schon? wenn ja, node:=B; wenn nein: node:=treeview.add(node,'B');

und das ganze dann möglichst rekursiv und fehlerfrei, und werte hab ich überhaupt noch keine eingetragen. -> N Haufen Arbeit!!

Und die Lösung des ganzen: TNRegView. funzt wunderbar.