XProfan

Deutsch

Registry.pcu und Registry.inc, Copyright by Thomas Schulz (aka ts-soft)
Veröffentlicht unter Lizenz der LGPL: [...]

Um die doch sehr eingeschränkte Funktionalität von XProfan zur Bearbeitung der Registry zu erweitern,
habe ich diese Unit/Include geschrieben.

Anforderungen:
ab Win95, NT4 mit installiertem IE4 oder höher
Nur mit XProfan 10 getestet

Parameter und Bedeutungen:
- KeyName$ = Der gesamte Key, inclusive Klasse, Profan kürzel werden unterstützt!
Beispiel: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersion
oder: HKEY_2SOFTWAREMicrosoftWindowsCurrentVersion

- ValueName$ = Eintrag (S3 in der Profan-Hilfe)

- Value$ oder Value& = Wert (S4 in der Profan-Hilfe)

- Index& = 0 - ?, für Enumerationen (ListSubKey, ListSubValue)

- Type& = Der Typ des Eintrags (SetString)
1 = REG_SZ (default)
2 = REG_EXPAND_SZ
3 = REG_BINARY
4 = REG_DWORD (für Long besser SetLong verwenden!)
7 = REG_MULTI_SZ

Da es sich bei dieser Unit/Include um eine Klasse handelt, ist als erstes immer ein Objekt zu erzeugen!

z.B:
Kompilieren Markieren Separieren

!$$U Registry.pcu
Declare Reg#
Reg# = New(Registry)

oder:
Kompilieren Markieren Separieren

!$$U Registry.pcu
Declare Reg#
Dim Reg#, Registry
Reg#.Init()  wichtig!

Am ende wieder mit Dispose freigeben!

Folgende ObjectVariable steht zur Verfügung:
.Error& (z.B. Reg#.Error&) <> 0 bedeutet Fehler

Folgende öffentliche Methoden gibt es:

Fehler$ = .GetErrMsg()
Ergebnis& = .DeleteKey(KeyName$)
Ergebnis& = .DeleteEmptyKey(KeyName$)
Ergebnis& = .DeleteValue(KeyName$, ValueName$)
Type& = .GetValueType(KeyName$, ValueName$)
Ergebnis$ = .ListSubKey(KeyName$, Index&)
Ergebnis$ = .ListSubValue(KeyName$, Index&)
Ergebnis& = .GetLong(KeyName$, ValueName$)
Ergebnis$ = .GetString(KeyName$, ValueName$) Funktioniert mit allen Registrytypen!
Ergebnis& = .SetLong(KeyName$, ValueName$, Value&) nicht existente Keys werden autom. erstellt!
Ergebnis& = .SetString(KeyName$, ValueName$, Value$[, Type&]) Type& ist Optional, default = REG_SZ!

Beispiele zu allen Methoden sind dabei!

Feedback willkommen!

Registry.zip	13 kB

Kurzbeschreibung:	Version 1.3

Hochgeladen:	06.12.2006

Ladeanzahl:
		Herunterladen

05.12.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

- Seite 1 -

Proc ?_Registry.Registry
Proc ?_Registry.Registry

05.12.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Jac
de
Lad

Verdammt. Ich meine korrigiert müsste es doch
Kompilieren Markieren Separieren

Proc ?_Registry.?_Registry

heißen, oder?!

Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP

05.12.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Müsste dann in der Klassendefinition nicht auch class ?_blub=+?_blub@ stehen?

05.12.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

RGH

[quote:ecb7539923=iF]Müsste dann in der Klassendefinition nicht auch class ?_blub = +?_blub@ stehen?

[/quote:ecb7539923]
Genau!

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

05.12.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

- Seite 2 -

Würde es einen Sinn machen, den Methoden auch einen Namespace zu geben? Ich denke mal, da die Methoden sowieso nur über die Klasse erreichbar sind (sollen), sollte der Namensraum der Klasse alles abdecken. Oder Irre ich jetzt

PS: Der Constructor hat nur Dummy-Function

, die Syntax mit New ist schöner

05.12.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Hm ja ich glaub Du irrst denn es geht darum das der Konstruktor nicht als solcher erkannt wird wenn er nicht auch das NameSpaceSign trägt.

05.12.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Ich würde mal sagen Festplattenplatz haben alle genug - im Bezug auf XProfan wäre da Geschwindigkeit angebrachter.

Geschwindigkeitsoptimierung, wie man sie für einen Registry-Editor oder ähnlich braucht, ist so in einer Unit nicht möglich. In einer Unit kann ich nicht im voraus Wissen, was als nächstes kommt, so das der Key bei jedem Vorgang geöffnet und wieder geschlossen wird, was natürlich bei direkter API-Nutzung beschleunigt werden könnte. Ich denke mal das erstellen von Registry-Editoren ist ein Ausnahmefall, so das die Geschwindigkeit vollkommen ausreichend ist. Am Code selber ist ansonsten IMHO nichts zu optimieren.

05.12.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Was ist mit Call statt external? Ich meine nur ums zu übertreiben...

05.12.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

[quote:eed748da24=iF]Was ist mit Call statt external? Ich meine nur ums zu übertreiben...

[/quote:eed748da24]
Der Gedanke ist mir auch schon gekommen, aber die Advapi32.dll ist ja bereits statisch zur Runtime gebunden, so das die schnelleren Delphi-Aufrufe zur Geltung kommen und es auch kein Sicherheitsleck gibt. Da hab ihr sowieso was verkehrt verstanden, denke ich. Lediglich die shlwapi.dll ist nicht statisch in die Runtime gebunden, aber die wird nur für 2 Methoden gebraucht (DeleteKey, DelteteEmptyKey), das sollte also nichts bringen.

05.12.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

[quote:f01e8c7b50]so das die schnelleren Delphi-Aufrufe zur Geltung kommen [/quote:f01e8c7b50]
Wird jetzt offtopic, aber ich denke das dem nicht so ist. Ich verweise ja hier xpse

auf ein BeispieCode an dem jeder nachprüfen kann das Call in diesem Fall deutlich! schneller ist. Oder reden wir aneinander vorbei?! Egal - ist eh offtopic.

05.12.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Update auf Version 1.2

iFs Vorschlag zur Beschleunigung umgesetzt

Die meisten API-Aufrufe laufen jetzt über Call, was wohl sinnvoll ist, da ja dieselbe API meist mehrmals benötigt wird. Jetzt ist es aber unbedingt erforderlich, das der Constructor ausgeführt wird, alternativ gibts jetzt die Methode .Init()
Das erste Posting, sowie die Beispiele wurden entsprechend angepaßt.

Gruß
Thomas

06.12.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Hm ja ich glaub Du irrst denn es geht darum das der Konstruktor nicht als solcher erkannt wird wenn er nicht auch das NameSpaceSign trägt.

Hab ich wohl vorher übersehen