Most efficient way of saving settings on a bot?

[Tontow]

  What would be the most efficient way of saving the settings for a bot?  A file? The windows registry? Some other means of storage? Best method of writing it? 

  I think the most effective way of gathering the information that needs to be saved is a textbox control array; if you want to add more options, then just add the needed textbox and add/modify code to handle/read the extra data. - Dose anyone have a better way?

[Warrior]

There was a topic on Ini vs Registry, search. I personally use the registry.

[Tontow]

Do you mean http://forum.valhallalegends.com/phpbbs/index.php?topic=9603.0 ?
Because it seems to be comparing Windows to Linux as pertaining to portability...

[Warrior]

Didn't take time to read, just remembered thread.

The way I do is

have a class:

each class contains properties for everything in my configuration

Code Select Expand


Public Property Get Username() as String
         Username = ReadRegistryFunctionLalala(Blah)
End Property

Public Property Let Username(ByVal strUsername as String)
        WriteRegistryFunction(strUsername)
End Property


[OnlyMeat]

It all depends on what data you are storing, if it's simple data, then go for the registry, if it's more complex, use an application data file.

[Tontow]

It all depends on what data you are storing, if it's simple data, then go for the registry, if it's more complex, use an application data file.

  Right now it's all text data: numbers for RGB format colors, username/pass, connection port, server ip, etc (and the rest of the basic stuff you would expect to be able to set on a bot). - Like I said,:

  I think the most effective way of gathering the information that needs to be saved is a textbox control array; if you want to add more options, then just add the needed textbox and add/modify code to handle/read the extra data.

Now back to the topic at hand:

  Registry: Is the more than one method of reading/writing to it? If so, then wich is better?

  Data file (.txt .ini etc.): Is the more than one method of reading/writing to each type of file? If so, then wich is better?  And wich format (.txt .ini etc) is the best?

  Please compair size of code vs speed.  Assume that the data that needs to be stored is the text from a textbox control array that is roughfly 100 long, each with text ranging anywhere from 1 to about 40-50 caraters long.

[OnlyMeat]

Right now it's all text data: numbers for RGB format colors, username/pass, connection port, server ip, etc (and the rest of the basic stuff you would expect to be able to set on a bot). - Like I said,:

You can store that kind of information in either, but application data files have the added advantage that they are easily transferable across machines, and you can encrypt information if you see fit. However, using the registry allows you store information without any consideration of it's location on disk.

Both have different pros/cons, but with simple data like that you could use either.

  Registry: Is the more than one method of reading/writing to it? If so, then wich is better?

Yes.  There are two methods as outlined below.

VB has built in application registry access functions in the form of SaveSetting()/GetSetting(). These are extremely simple to use and do the job.

Alternatively, you can use the raw API registry functions if you prefer greater control. These come in the form:-

RegOpenKey()
RegQueryValueEx()

etc...

Of course these are more complex to use, especially through vb. The built in vb functions make those calls internally, so you are infact calling the same API.

  Data file (.txt .ini etc.): Is the more than one method of reading/writing to each type of file? If so, then wich is better?  And wich format (.txt .ini etc) is the best?

Yes. .txt and .ini are just file extensions. They mean nothing except to the operating system which associates them with programs. The 'PrivateProfile'  format can be used in any file, with any extension, .txt, .ini, .dat. what ever you like.

The PrivateProfile format in windows consists of the following elements:-

[SECTIONNAME]
KEY=VALUE

It's pretty simple. Windows has built in functions for reading and writing the values using this format.

Some of the functions used to do this:-

GetPrivateProfileString()
WritePrivateProfileString()

etc...

Note those are API functions, not built in vb ones.

As i mentioned, .txt files can contain anything, they don't have a specific format. If you choose to use your own format   rather than a PrivateProfile, then you must choose how the file is composed and implement custom parsing etc. obviously this requires more effort, and will probably be less efficient than using PrivateProfiles.

Please compair size of code vs speed.  Assume that the data that needs to be stored is the text from a textbox control array that is roughfly 100 long, each with text ranging anywhere from 1 to about 40-50 caraters long.

Using PrivateProfiles will certainly be less code, and probably faster. The number of characters stored isn't an issue with PrivateProfile files, the OS takes care of all of that for you.

[UserLoser.]

Code Select Expand


Option Explicit

Public Enum e_KeyRoot
    HKEY_LOCAL_MACHINE = &H80000002
End Enum

Public Enum e_KeyAccess
    KEY_ALL_ACCESS = &HF003F
End Enum

Public Enum e_RegOption
    REG_OPTION_NON_VOLATILE = &H0
End Enum

Private m_KeyHandle As Long

Private Sub Class_Terminate()
    If (m_KeyHandle > 0) Then
        Call CloseKey
    End If
    m_KeyHandle = 0
End Sub

Public Property Get KeyHandle() As Long
    KeyHandle = m_KeyHandle
End Property

Public Function OpenKey(ByVal KeyRoot As e_KeyRoot, ByVal SubKey As String) As e_Win32Error
    OpenKey = RegOpenKeyEx(KeyRoot, SubKey, 0, KEY_ALL_ACCESS, m_KeyHandle)
End Function

Public Function CloseKey() As e_Win32Error
    CloseKey = RegCloseKey(m_KeyHandle)
End Function

Public Function CreateKey(ByVal KeyRoot As e_KeyRoot, ByVal SubKey As String) As e_Win32Error
    CreateKey = RegCreateKeyEx(KeyRoot, SubKey, 0, vbNullString, REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, ByVal CLng(0), m_KeyHandle, 0)
End Function

Public Function EnumKey() As Collection
    If (m_KeyHandle > 0) Then
        Dim SubKeys As Long, LastWriteTime As FILETIME
        If (RegQueryInfoKey(m_KeyHandle, vbNullString, 0, 0, SubKeys, 0, 0, 0, 0, 0, 0, LastWriteTime) = ERROR_SUCCESS) Then
            Dim I As Long, KeyName As String
            Const MaxLength As Long = 256
            Set EnumKey = New Collection
            KeyName = Space$(MaxLength)
            For I = 0 To SubKeys - 1 Step 1
                If (RegEnumKeyEx(m_KeyHandle, I, KeyName, MaxLength, 0, vbNullString, 0, LastWriteTime) = ERROR_SUCCESS) Then
                    Call EnumKey.Add(KeyName)
                End If
            Next I
        End If
    End If
End Function


RegQueryInfoKey was giving troubles a while ago, so I hardcoded MaxLength to 256.

[Tontow]

thankyou OnlyMeat, that is a near perfict reply and thanks UserLoser for the example.

Can anyone else best there replys?

[MyndFyre]

Well, I haven't read the replies.  Regarding registry/INI functions, you're going to lose the portability if you use GetPrivateProfileString anyway (if you're using the API functions to do it).

Beyond that, Microsoft's "Certified for Windows XP" guidelines require that you store user-specific data -- such as configuration settings -- within the registry or within the user's private profile/documents folders.  Specifically, data that is core to the functioning of the software, such as configuration settings, goes in the registry.

Don't know if that has any relevance for you whatsoever.

[Dyndrilliac]

Ideally you want to store user-sepcific program settings in the registry. This allows computers with multiple users to not need a seperate settings file for each user.

[OnlyMeat]

Ideally you want to store user-sepcific program settings in the registry. This allows computers with multiple users to not need a seperate settings file for each user.

That is simply not true. You can store user specific settings in application data files. You can store user specific settings in C:\Documents and Settings\<USER>\Application Data\.

The shell even provides a platform independent interface to determine this directory:-

Code Select Expand


HRESULT SHGetSpecialFolderLocation(          HWND hwndOwner,
    int nFolder,
    LPITEMIDLIST *ppidl
);


If you specify CSIDL_APPDATA, it will return the current user's Application Data directory. Alternatively you can use the directory for all users with CSIDL_COMMON_APPDATA.

[Dyndrilliac]

How is what I said not true? I said that you could use the registry to store user-specific settings, and that for this type of storage they would be the ideal method. Nothing more. I never said it was the only way. Using Application Data storage is ideal for databases, unique file formats and other things of that nature. Simple variable filling is best when used in conjunction with the registry.

[OnlyMeat]

Ideally you want to store user-sepcific program settings in the registry. This allows computers with multiple users to not need a seperate settings file for each user.

You are implying that you have to use the registry to store data when a system has multiple user accounts. This is simply not true, you can store user specific application data files or data files for all users, in exactly the same way the registry allows you to do this.

[Dyndrilliac]

I said "Ideally", meaning that this is generally accepted as the prefered way of doing it. Application Data is best used for things like databases or lists used by software. The Registry is for user-specific Value-to-Variable program settings.

I didn't imply anything other than what I have just stated. Anything other than that was purely imagined on your part.