This can be summed up with simply, use Scripting.Dictionary.
One of the problems with VB6 is maintaining version compatability. If the parameters on the public object’s functions change you break version compatability. This can be a real hassle. VB doesn’t provide for overloading. So, you can’t add another function of the same name with different parameters. VB does provide for Optional parameters and I’m not sure that would require breaking compatability, I think it would.
The best way to avoid this at the outset is to pass in a Scripting.Dictionary object instead of explicit parameters. This can make maintence quite a hassle since the next programmer doesn’t know what parameters are required or exactly what to name them. However, it does let you pass in variable parameters and maintains version compatability pretty easily.
I was recently reminded of this while looking at some c# code. It used a generic object to hold whatever as parameters. c# is particularly nice at this, because you can include objects, arrays, strings, integers, whatever. Whereas, a dictionary object will limit you to values you can hold in a string.
If the project is big enough it would be worth creating your own “can hold anything” object using c++ or vb6. And pass that in/out.
Which brings up another use for Dictionaries, as the return variable. For some reason, most languages perpetuate the idea the a function returns one things. My guess is this goes back to FORTRAN (FORmula TRANslation and it’s mathematical roots). Of course, you can pass in variables that also pass out using ByRef and address pointers. But this is really a hack around the syntactical design mistakes of the language designers and takes advantage of the fact that computers refer to everything by address number. What if they didn’t?
Return the Dictionary objects instead of the discrete integer, string, etc. types. This will let you return more than one variable without worrying over ByVal/ByRef placements. Scripting.Dictionary is on every MS computer since Win2K or older. It’s highly unlikely this dependency is going to cause a problem and if it does the target computer has a lot worse things wrong with it than your VB6 app/applet.