I can see using a parameter array of control references, but
in the OP's situation, the controls are unbound so I don't
see how their control source can contribute any information.
Well, in that case, he'd have to do is some other way, perhaps with
names. With unbound forms I usually name the control what the
ControlSource would be if it were bound.
There's also the issue of the result being the value of an
expression. While those concerns can be dealt with one way
or another, explaining all these generalities to someone
that needed to ask the original question is, IMO, not
productive.
Well, it all depends on what you're trying to accomplish. If you
want to look up multiple fields, a generalized function can do that,
and return it as an array. How much knowledge the internals of the
function need of context is up to you -- or you can make it dumb and
just return a paired array of fieldname/value, and then do with it
what you want in the calling context.
Using a subform might be simpler than any of these code
techniques.
Sure. But I was only looking at the proposed solution, which I
consider very problematic, and trying to offer alternatives. I don't
mean to imply that my solution will be superior in all cases, just
that it's definitely worth considering.
To me concatenating a bunch of stuff together just so you can pass a
bunch of values in a single argument is a sign of a problem, that
you need a more robust solution.
I never use OpenArgs of forms for anything but a single argument,
and never for passing data into the form. For that, I always use a
standalone class module. This has the advantage of making the class
usable in multiple circumstances, and the forms/reports usable
without needing to know anything about their calling context -- they
only need to know how to get the needed data out of the class
module. Depending on the context, that would be a better solution
than my multi-value function.
