Associative array or alike 5

[Overdoos]

Hey,

This is more a quest for your opinions and some information then a hardcore technical question...

For an application, I need a translation-possibility. I've done this by setting up a DB containing a key and then the 'value' for each language

Table layout:
[ KEY ] [LANG 1] [LANG 2] [LANG 3] [LANG 4]

It all works, but every time something needs translation, it makes a hit on the DB. This is true for nearly all labels I use on my forms, but sometimes data needs translation as well.

You can imagine the amount of hits the DB gets when the app starts up or if someone selects another language-option.

To counter this massive DB-traffic, I thought of simply loading every description for the correct language in an associative array [KEY] -> [LANG]. This would reduce the DB-hits a great deal because the translation table would only be accessed when the app starts up, or when another language is selected.

The problem I come across is that there does not seem to be a structure for associative arrays in VB6.

I did find the DICTIONARY object that would seem to do what I want, but I cannot get it to work.

Do you know of any ways to go about this problem? Did I miss something and are associative arrays available in VB6? Are you the expert in the VB6 dictionary-object that is willing to explain me how it works? Got better alternatives?

Please let me know. I'm willing to evaluate all proposed options here...

 

[EBGreen]

First reference scripting. Then Dim an object as Scripting.Dictionary. Now you can use the .Add method to add a key value pair to the dictionary. If you have already done all of these things, then what does your code look like and what error are you getting?

[blue]"Well, once again my friend, we find that science is a two headed beast. One head is nice, it gives us aspirin and other modern conveniences,...but the other head of science is BAD! Oh, beware the other head of science, Arthur; it bites!!" - The Tick[/blue]

 

[jjames]

You could use a collection object...

Paste the following into a form and add a command button

Option Explicit
Private col As Collection

Private Sub LoadLanguage()
    
    Set col = New Collection
    
    col.Add "Alpha", "a"
    col.Add "Beta", "b"
    col.Add "Gamma", "g"
    col.Add "Delta", "d"
    
End Sub

Private Function Translate(sWord As String) As String

    On Error Resume Next

    Translate = col(sWord)
    
    If Err.Number = 5 Then
        'Word not in collection
    End If

End Function

Private Sub Command1_Click()
    MsgBox Translate(InputBox("Enter Key:"))
End Sub

Private Sub Form_Load()
    LoadLanguage
End Sub

Private Sub Form_Terminate()
    Set col = Nothing
End Sub

 

[EBGreen]

jjames's solution is better than a dictionary object.

[blue]"Well, once again my friend, we find that science is a two headed beast. One head is nice, it gives us aspirin and other modern conveniences,...but the other head of science is BAD! Oh, beware the other head of science, Arthur; it bites!!" - The Tick[/blue]

 

[Overdoos]

I was going forward with the dictionary stuff (I forgot to reference the scripting), but if you both think that the collection-object is a better choise I thing I'll try that as well.

I'll try to keep you informed...

Thank you for your time and expertise (stars awarded to both)

 

[Overdoos]

One extra question though...

Anybody got an idea how I can make this collection really public?

I defined it as being 'public' in one module, and then I want to populate it in another, but this generates errors (err.number = 91)

 

[Swi]

You could also use the dictionary object:

Option Explicit
Private Dict As Dictionary

Private Sub LoadLanguage()

Set Dict = New Dictionary

Dict.Add "a", "Alpha"
Dict.Add "b", "Beta"
Dict.Add "g", "Gamma"
Dict.Add "d", "Delta"

End Sub

Private Function Translate(sWord As String) As String

On Error Resume Next

If Dict.Exists(sWord) Then
Translate = Dict(sWord)
Else
Translate = "Not In Dictionary"
End If

End Function

Private Sub Command1_Click()
MsgBox Translate(InputBox("Enter Key:"))
End Sub

Private Sub Form_Load()
LoadLanguage
End Sub

Private Sub Form_Terminate()
Set Dict = Nothing
End Sub


Swi

 

[Overdoos]

thanks, but I've decided to use a collection to tackle this problem. The PUBLIC stuff has been solved too (added the magic word 'NEW' in the definition and suddenly everything was OK).

But, yes, I've encounterd yet another problem...

How does one clear an entire collection?

I need to clear all elements of this collection before I can repopulate it because the KEYs will always have the same value for the different languages.

 

[Swi]

If you want to completely empty a collection the most efficient way would be to destroy it and then recreate it.

Set col = Nothing
Set col = New Collection

If you would use the dictionary object you could use:

Dict.RemoveAll

Actually, I would have to disagree with TomThumbKP. The Dictionary Object is a enhancement of the Collection object.

Swi

 

[Overdoos]

Swi,

I've looked into both and they both seemed to have their pros and cons. The main reason I chose for the collection is that is seemed simpler to implement (I'm only a newby to VB and I cannot say that it won my heart) -and- as a bonus it does not need the microsoft scripting reference.

Thank you for you kind explenations, but I'll stick with the collection for this problem (unless it proves totally unworkable for what I have in mind.)

When it comes to removing all objects I would rather not have to recreate it (although I must admit that it looks the most efficient way to go about it). For the moment I loop through it, deleting everything I come across. It may not be the most efficient way, but it works

Looking forward to extra comment though.

 

[EBGreen]

If you are going to be dependent on the dictionary methods that are not available for a collection, then I would agree that a dictionary is better. If however all you need is a purely associative array to hold data, then I believe the collection has less overhead. Just my $2.0E-2

[blue]"Well, once again my friend, we find that science is a two headed beast. One head is nice, it gives us aspirin and other modern conveniences,...but the other head of science is BAD! Oh, beware the other head of science, Arthur; it bites!!" - The Tick[/blue]

 

[Swi]

Here is a link that explains the pros and cons of both and also has some great examples:

http://users.mikrotec.com/~jpeyton/DataStructures/Discussion27.html

Swi

 

[Swi]

According to the above link the dictionary has these advantages:

The Dictionary gets rid of many of the shortcomings of the Collection. It allows us with

a method to access all of its Keys,
a method to determine if a given Key exists,
a method to change a Key,
a method to change the value of an Item,
a method to remove all items at once,
a method to control case sensitivity,
and it is considerably faster than the Collection.

Swi

 

[EBGreen]

That is a good reference. According to it, a dictionary is faster than a collection. If this is true, then I may never use a collection again. I'll have to do some looking into the matter. The author does mention one important caveate and that is that to use the dictionary object, the end user must have the appropriate DLL on their machine. The author also missed on of what I consider to be the most important uses of dictionaries and that is for complex data structures. Since the value of an item in the dictionary can be essentially anything, it could be an array, or even another dictionary. I make use of this often. I come form a perl background where hashes of hashes of hashes are not at all rare. Oh, and a star for Swi in thanks for pointing to a good reference.

[blue]"Well, once again my friend, we find that science is a two headed beast. One head is nice, it gives us aspirin and other modern conveniences,...but the other head of science is BAD! Oh, beware the other head of science, Arthur; it bites!!" - The Tick[/blue]

 

[Swi]

Thanks. I just started making use of the Dictionary object in a few of my programs. I'll never go back to collections. Good point about complex data structures.

Swi