Hallo Gemeinde,
ich habe mit
regedit /e dateiname "HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Devices"
die Einträge für alle auf einem XP-Rechner installierten Drucker in eine Textdatei exportiert. Wenn ich diese Textdatei mit einem VB-Skript öffne, erhalte ich nur verschlüsselten Text (z.B. yBS). Mit editor kann ich die Einträge sauber lesen.
Was kann ich tun, dass ich die Datei mit dem Skript auswerten kann (brauche die Druckernamen für Einträge in einer Datei).
Wäre schön, wenn mir jemand helfen könnte
Vielen Dank
Klaus
Programmieren - alles kontrollieren 4.941 Themen, 20.708 Beiträge
Wäre es nicht einfacher, die Daten direkt aus der Registry aus zu lesen?
Das so zu machen verstehe ich schon, man bleibt damit portabel bei verschiedenen Windows-Versionen und es geht schön einfach. Hört sich eher so an als hat dein VB-Skript zum öffnen der Datei einen Fehler.
Zeig mal den Code-Schnipsel bitte.
In wie fern wird man dadurch portabler? Durch die win32-API (wird man aber eher nur selten direkt nutzen) sind Funktionen definitiert über die man auf die Registry zugreifen kann, diese Funktionen sind auf allen win32-Systemen vorhanden...
Hast Du mal die Registry-Zugriffs-Klassen von Thomas Wölfer gesehen?
Hat er vom Netz genommen aber im Filesharing gibts die noch.
Da unterscheidet sich schon einiges von 9x zu NT/2000 zu XP.
Wenn er nur unter dem Scripting-Host arbeitet Gute Nacht.
Mir ist keine Standard-ActiveX-Komponente bekannt die denn lockeren Zugriff ermöglicht.
Wenn doch klär mich auf. Ansonsten wie gesagt: seine Variante ist einfacher&unanfälliger(naja okay im Moment ist das nicht :p), ich mag einfache Lösungen.
Also oben schreibt er was von VB (zumindest der Titel ist da mehr als eindeutig), und da sollte es doch eigentlich eine bequeme Zugriffsmöglichkeit über VB-eigene Funktionen zum Zugriff auf die Registry geben (sollte es sowas wirklich nicht geben, dann wären meine bisherigen Vorurteile doch eher zu vernachlässigen...), die solche Aufrufe Kapseln - an der Basis-Funktionalität hat sich seit Win95/NT ja nix geändert...
einfacher
Also einen Parser zu bauen um die Datei-Inhalte wieder in eine zur weiterverarbeitung brauchbare Form zu bringen finde ich nicht umbedingt einfacher, Dateisystemoperationen liefern darüber noch höhere Fehlerquellen (wg. mangelnder NTFS-Schreibrechte)...
Gruß
Borlander (der auch einfache Lösungen mag, und womöglich deshalb mit Borland-Delphi besser bedient ist? ;-)
Das Brandenburg-Problem kann grundsätzlich überall auftreten bei NT-Systemen, ist ja auch gut so ;).
Und da der Versucher dieses Threads keinen Piep mehr von sich gibt hat sich das Problem ja sowieso erledigt.
VB-eigene Methoden geben nur lesenden und schreibenden Zugriff auf einen bestimmten RegPath(VBandVBASettings irgendwo bei HKEY_USER/Microsoft glaub ich). Einfach aber beschränkt. Eher was wenn man nur was fürs eigene System schreiben will, anonsten siehts auch blöd aus, die meisten Programmier wollen sich da schon ordentlich unter ihrem Namen/Firma/Logo eintragen.
Alles andere muss entsprechend programmiert werden, es existieren wiederum verschiedene Freeware-Klassenmodule im Internet die ich getestet und habe und die nicht auf allen Win-Systemen funktioniert haben(nutze VM-Ware). Eine ActiveXDLL zumindest von MS ist mir wie gesagt nicht bekannt.
Vermutlich gibts unter dem .NET Framework aber eine Registry-Klasse.
Soferns dich tatsächlich interessiert: http://www.shadoware.de/files/vb/registry.zip
Das noch beste öffentliche Registry-Codemodul für VB und funktioniert wie gesagt auch nicht auf allen System, for each auf subkeys haut auf neueren systemen nicht hin usw. Die Win32 Api für Ini-Files(das keine spezifischen unterschiede zwischen 9x und NT-Systemen aufweist) und so eine Struktur hat das Ergebniss-File ja plus die üblichen einfachen Open/Read Befehle sind für mich da persönlich einfacher aber das ist vielleicht garkeine Frage von besser und schlechter sondern eher persönlicher Vorlieben. Es gibt sicher Szenarien wo Du eindeutig recht hast z.B. wenn der Benutzer keine Rechte hat, das Programm aber schon und man den Benutzer möglichst aussen vor lassen will, andererseits wenn das ganze nur von 12 bis Mittag halten soll und Teil irgendeiner internen naja sagen wir mal einer internen Datenüberleitungsoperation einer kleinen Firma ist und es schnell gehen muss sieht die Sache vielleicht anders aus, das Brandenburg-Problem dürfte dann eh keine Rolle spielen. So, sorry zuviel Kaffee da werd ich schnell redselig.