| |
|
|
- page 1 - |
|
| Registry.pcu et Registry.inc, Copyright by Thomas Schulz (aka ts-soft) Veröffentlicht sous Lizenz qui LGPL: [...]
Um qui doch très eingeschränkte Fonctionnalité de XProfan zur Bearbeitung qui Registry trop erweitern, habe je cet Unit/Include geschrieben.
Anforderungen: ab Win95, NT4 avec installiertem IE4 ou bien höher seulement avec XProfan 10 getestet
paramètre et Bedeutungen: - KeyName$ = qui gesamte Key, inclusive super, Profan kürzel volonté soutenu! Beispiel: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersion ou bien: HKEY_2SOFTWAREMicrosoftWindowsCurrentVersion
- ValueName$ = Eintrag (S3 dans qui Profan-Aider)
- Value$ ou bien Value& = Wert (S4 dans qui Profan-Aider)
- Index& = 0 - ?, pour Enumerationen (ListSubKey, ListSubValue)
- Type& = qui Typ des Eintrags (SetString) 1 = REG_SZ (default) 2 = REG_EXPAND_SZ 3 = REG_BINARY 4 = REG_DWORD (pour Long besser SetLong verwenden!) 7 = REG_MULTI_SZ
là es sich chez cette Unit/Include um une super handelt, ist comme erstes toujours un objet trop erzeugen!
z.B: KompilierenMarqueSéparation ou bien: KompilierenMarqueSéparation au sommet wieder avec Dispose freigeben!
Folgende ObjectVariable steht zur Disposition: .Error& (z.B. Reg#.Error&) <> 0 bedeutet faute
Folgende öffentliche Methoden gibt es:
faute$ = .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 avec allen Registrytypen! Ergebnis& = .SetLong(KeyName$, ValueName$, Value&) pas existente Keys volonté autom. erstellt! Ergebnis& = .SetString(KeyName$, ValueName$, Value$[, Type&]) Type& ist optionnel, default = REG_SZ!
Beispiele trop allen Methoden sommes dabei!
Feedback willkommen! |
|
|
| |
|
|
|
| |
|
- page 1 - |
|
| Proc ?_Registry.Registry Proc ?_Registry.Registry
|
|
|
| |
|
|
|
Jac de Lad | |
|
| 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 ▲ |
|
|
|
|
| Müsste ensuite dans qui Klassendefinition pas aussi class ?_blub=+?_blub@ stehen? |
|
|
| |
|
|
|
RGH | [quote-part:ecb7539923=iF]Müsste ensuite dans qui Klassendefinition pas aussi class ?_blub = +?_blub@ stehen? [/quote-part:ecb7539923] oui c'est ca!
Salut 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 ▲ |
|
|
|
| |
|
- page 2 - |
|
|
| Würde es une Sinn faire, den Methoden aussi une Namespace trop donner? je denke la fois, là qui Methoden sowieso seulement sur qui super erreichbar sommes (devoir), sollte qui Namensraum qui super alles abdecken. ou bien Irre je maintenant
PS: qui Constructor hat seulement Dummy-Function , qui Syntax avec New ist plus beau |
|
|
| |
|
|
|
| Hm oui je glaub Du irrst car und dir tout autor cela qui Konstruktor pas comme solcher erkannt wird si il pas aussi cela NameSpaceSign trägt. |
|
|
| |
|
|
|
| iF
je serait la fois dire Festplattenplatz avons alle genug - im Bezug sur XProfan wäre là Geschwindigkeit angebrachter.
Geschwindigkeitsoptimierung, comment on vous pour une Registry-Editor ou bien ähnlich braucht, est dans einer Unit pas possible. dans einer Unit peux je pas d'avance savons, quoi comme nächstes venez, so cela qui Key chez chaque Vorgang ouvert et wieder geschlossen wird, quoi naturellement chez direkter API-Nutzung beschleunigt volonté pourrait. je denke la fois cela erstellen de Registry-Editoren est un Ausnahmefall, so cela qui Geschwindigkeit vollkommen ausreichend ist. Am Code selber ist ansonsten IMHO rien trop optimaliser. |
|
|
| |
|
|
|
| quoi ist avec Call statt external? je mon seulement ums trop übertreiben... |
|
|
| |
|
|
|
| [quote-part:eed748là24=iF]quoi ist avec Call statt external? je mon seulement ums trop übertreiben... [/quote-part:eed748là24] qui idée c'est moi aussi déjà gekommen, mais qui Advapi32.dll ist oui bereits statisch zur Runtime attaché, so cela qui schnelleren Delphi-Aufrufe zur Geltung venons et es aussi ne...aucune Sicherheitsleck gibt. là hab son sowieso quoi verkehrt verstanden, denke je. Lediglich qui shlwapi.dll ist pas statisch dans qui Runtime attaché, mais qui wird seulement pour 2 Methoden gebraucht (DeleteKey, DelteteEmptyKey), cela sollte alors rien apporter. |
|
|
| |
|
|
|
| [quote-part:f01e8c7b50]so cela qui schnelleren Delphi-Aufrufe zur Geltung venons [/quote-part:f01e8c7b50] Wird maintenant offtopic, mais je denke cela dem pas so ist. je verweise oui ici xpse sur un BeispieCode à dem chacun nachprüfen peux cela Call dans diesem le cas deutlich! plus rapide ist. ou bien reden wir aneinander vorbei?! égal - ist eh offtopic. |
|
|
| |
|
|
|
| Update sur Version 1.2
iFs Vorschlag zur Beschleunigung mise en œuvre
qui meisten API-Aufrufe courir maintenant sur Call, quoi wohl sinnvoll ist, là oui dieselbe API meist plusieurs fois nécessaire wird. maintenant ist es mais absolument erforderlich, cela qui Constructor fonctionnement wird, alternativ gibts maintenant la méthode .Init() cela erste Posting, sowie qui Beispiele wurden entsprechend ajusté.
Salut Thomas |
|
|
| |
|
|
|
| |
|
| |
|
|