I have a small application (about 8 Forms) which uses Dictionaries to store small amounts of data e.g. abbreviations of country names (index) and the full name (value) in each of several languages (one Dictionary per language in this example). I have several such Dictionaries which are identical in 3 or 4 forms' code; it would be easier to maintain one Public Dictionary for each set of data, but declaring a Dictionary in Module1.bas hasn't been successful. Declaring it as Public and SETting it in the first form hasn't worked either. Would someone suggest a solution or point me to an online source to help with this? Many thanks.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Using a global Dictionary to share data between programs 1
- Thread starter traceyr
- Start date
dilettante
MIS
The short answer is to use indexed files.
This becomes a longer answer if you are doing any updating on the fly, since you need to be concerned about locking records, inserting records, re-indexing records, etc.
However this is the kind of thing that embedded databases that support concurrent access are all about! And Windows has Jet 4.0 preinstalled so there is nothing to buy and nothing to deploy but the data.
Drives are faster, RAM is larger, and disk caching has gotten smarter and smarter over the years. This means performance often isn't an issue.
An alternative for very simple cases might be to use a shared out of process server (ActiveX EXE) to house your Dictionary objects. This is one of the reasons they exist.
This becomes a longer answer if you are doing any updating on the fly, since you need to be concerned about locking records, inserting records, re-indexing records, etc.
However this is the kind of thing that embedded databases that support concurrent access are all about! And Windows has Jet 4.0 preinstalled so there is nothing to buy and nothing to deploy but the data.
Drives are faster, RAM is larger, and disk caching has gotten smarter and smarter over the years. This means performance often isn't an issue.
An alternative for very simple cases might be to use a shared out of process server (ActiveX EXE) to house your Dictionary objects. This is one of the reasons they exist.
- Thread starter
- #3
Hi and thanks for the quick response. I should have been more explicit: this is a single-user system, with several self-contained programs, so there are no issues with record-locking etc. I'm implementing new functionality and had hoped that a public dictionary would be a way to share relatively small amounts of data (< 5000 index/value pairs) between programs. If not, then a file-based solution would be OK, or even public arrays - but dictionaries would be so much easier to use.
dilettante
MIS
Yes I know you meant one user on one system, that's why I suggested using a light weight embedded database technology like Jet.
Locking isn't about users, it's about actors. If you have multiple programs that can all update the same resource then you still need locking or you risk data integrity problems.
Locking isn't about users, it's about actors. If you have multiple programs that can all update the same resource then you still need locking or you risk data integrity problems.
- Thread starter
- #5
Thanks once more. I've never used Jet, so that's something I can look into. I also wondered about passing the contents of the local dictionary via two public arrays (using the Keys and Items properties of the dictionary), iterating through the arrays to Add them into the local dictionary in the 'receiving' program. Presumably the original order of the dictionary entries is maintained each array.
-
1
- #6
dilettante
MIS
Hmm, I'm not sure a "public array" does what you hope it might.
I did throw together a simple demo showing how to share a Dictionary (without any locking logic, just the simplest example possible). See Sharing Objects via an ActiveX EXE.
That might or might not do what you need.
Ideally you'd wrap the Dictionary providing your own interface that incorporates locking and probably an optional "change" event to signal all clients about any updates (add, change, delete).
You'd probably also want to persist the data to disk but that's fairly easy to do in the Connector Class's Initialize and Terminate event handlers.
And for that matter the ActiveX EXE could host multiple shared Dictionaries, or even a shared Collection of Dictionary objects. Collections can be superior because it is easy to create a custom collection Class and very clumsy to create a custom "dictionary" style Class.
The main thing I dislike about this approach is that the Dictionary has those nasty, expensive Keys and Items methods. The only way to "see" a Key requires retrieving the Keys array. These copy the entire Dictionary content into arrays, and can be expensive to marshal across processes. Not so awful as to be unusable within one machine, though I'm not sure I'd want to do it across even a fast LAN.
VBA.Collection and Scripting.Dictionary each offer different strengths and weaknesses, so the choice requires some thought.
I did throw together a simple demo showing how to share a Dictionary (without any locking logic, just the simplest example possible). See Sharing Objects via an ActiveX EXE.
That might or might not do what you need.
Ideally you'd wrap the Dictionary providing your own interface that incorporates locking and probably an optional "change" event to signal all clients about any updates (add, change, delete).
You'd probably also want to persist the data to disk but that's fairly easy to do in the Connector Class's Initialize and Terminate event handlers.
And for that matter the ActiveX EXE could host multiple shared Dictionaries, or even a shared Collection of Dictionary objects. Collections can be superior because it is easy to create a custom collection Class and very clumsy to create a custom "dictionary" style Class.
The main thing I dislike about this approach is that the Dictionary has those nasty, expensive Keys and Items methods. The only way to "see" a Key requires retrieving the Keys array. These copy the entire Dictionary content into arrays, and can be expensive to marshal across processes. Not so awful as to be unusable within one machine, though I'm not sure I'd want to do it across even a fast LAN.
VBA.Collection and Scripting.Dictionary each offer different strengths and weaknesses, so the choice requires some thought.
- Thread starter
- #7
Thanks for the very thorough help, especially with the worked example. For my immediate purposes (it's really just analysing and reporting business results, no updates involved) I have got the quick (and slightly grubby!) "Dictionary A -> two public arrays -> Dictionary B" method working, but I shall certainly look into the Jet option as well. The Tek-Tips community has come up trumps again.
- Status
