Ok first some introduction.
This class is an attempt to make access to windows registry functions more convinient to use and to address some, possibly subjective, shortcomings of the ones already supplied with lazarus/fpc distribution.
I admit i have only recently started to learn about classes, so the code i post will most likely look very plain and/or lacking wisdom, this is where constructive criticism, comments and ideas are welcome to help me improve it.
The initial reason is that i wanted to make a small registry scanning utility. I succeeded to use TRegistry class but have soon realized it lacked full range of abilities i needed to make such program. Namely, inability to use class members to retrieve REG_MULTI_SZ and some others. TRegistry class only supported rdString, rdExpandString, rdBinary, rdInteger (you can easily recognize REG_xxx equivalents).
I looked around for solution but have always come to same conclusion and advice given in this forum : use original TRegistry class and if needed, add missing functionality yourself.
And this would be for me a normal course of action so i have looked into the class organization to see what needs to be changed and/or added to make it work as i needed.
This attempt failed since i realized this class was spread over at least two units/files and had structure too complicated for my taste. I assume this is so to make it cross-platform, so some capabilities had to be removed. This compromise, combined with aforementioned complexity lead me to make my own registry class i dubbed TRegistryExtended to reflect some additions i made.
This class is made with following in mind:
-some operations are made automatic to ease usage
-it never keeps a lock on any handle in registry
-it assumes that some conditions must be fullfiled, thus it will raise exception in such instances
-it always tries to execute requested action and if it fails, it will return error and keep last good state
-it does not do any processing on data, only gives organized access to it, this means it will not only return raw data from windows API it will also give their return codes
Some basic ideas shown in TRegistry are retained and built upon.
The class itself has following public members :
* Constructor Create : overloaded, it can accept access type (KEY_xxx) or it can also receive root key in HKEY or string form. if it cannot complete, exception will be raised.
* Read property Status : status of last completed operation, not only original return code from windows API, but also from internal functions. This may be point of discussion as i am also not happy with this. I would like to try to define custom error codes that can be passed along same property.
* Read/write property Path : i was struggling with basic idea how this class should function to keep some complexity away from a programmer, ie to avoid the need to keep at all times a valid path to key.
* Read/write property RootH : HKEY version of root key. setting it "retargets" entire class to new root and resets path to blank.
* Read/write property RootS : string version, but otherwise same as HKEY before, for convinience only if programmer is doing some kind of text file I/O.
* Read/write property Access : access type. Can be changed at any time. Class does not assume if user wants to perform registry write operation to set access automatically to type of KEY_ALL_ACCESS or similar. Operation will fail if proper access is not set.
* Read property Key : for convinience, it is copy of last subkey in path string.
* Read property DateAccessed : in TDateTime format.
* Procedure GoParent : overloaded. Basic no-parameter-version sets path one key level up. With parameters, it accepts string in form of '\\\\' or '\\subkey\subkey' . Each backslash causes path to go one level up. If additional keys are supplied it will try to go up level then down
level.
* Procedure Refresh : nothing special. It only refreshes state of current path/key. Good for some basic tracking of changes. Not a replacement for more appropriate registry notification API.
* Procedure CreateKey : Creates a key under a current key. Requires subkey and Boolean determining if this key is to be set as currently working key. It only creates non-voltile keys !
* Procedure DeleteKey : Deletes a key. Requires path string argument and Boolean determining deletion of all subkeys. Path can be relative (with preceeding '\') or absolute (without preceeding '\'). I had to add declaration for SHDeleteKey from 'shlwapi.dll', or else i had to code a whole recursion procedure just for this
* Function KeyExists : check for existance of key. Requires key name but it can formatted like path with '\' as first character in string denoting relative path. Returns Boolean. Does not affect status or cause any processing.
* Read property SubKeyCount : Integer number showing how many subkeys are present under a current key.
* Array read property SubKeyName : returns string name of subkey determined as integer.
* Array property SubKeyDate: returns TDateTime of subkey.
* Function ValueExists : same as KeyExists(), but needs value name string. Returns Boolean.
* Procedure DeleteValue : needs subkeyname and value name string.
* Procedure CreateValue : needs subkey name, value name, DWORD for value type, int for size and a pointer to a datablock. By providing "raw" access to underlying API, i avoided additional wrapping into some "my code". It's as raw as it can be.
* Read property ValueCount : int showing number of values inder current key.
* Read array property ValueName : like SubKeyName[] only for values.
* Read property ValueType : same as above.
* Read property ValueSize : same as above.
* Read property ValueData : same as above, but pay attention this is a pointer to internally pre-alloced memory. do not try to FreeMem() it yourself !
Note also that all root/path changing and write/delete operations cause automatic refresh of current key and all date/subkey/value information that can be retrieved (available through RegEnumxxx () functions).
All subkeys and values are kept in internally allocated memory that is dynamically assigned as needed. I could have gone the TStringList route, but decided against it since i needed to be able to keep varied types of data and it had too much complexity for such a (IMHO) simple functioning.
Value data is kept in dynamically allocated typed blocks with pointers to actual value data.
Also note that i have done only minimal testing, speed and eventual memory leaking are not tested ! Createxxx() and Deletexxx() are not tested, mostly only reading-type functions. This one is first complete alpha, fresh as it gets !
So, here it (FINALLY
) comes, the actual source !
Recent
