I would like to call a function that "returned" several values

[MLH]

I would like to call a function that "returned" several values - all
of which are relevant to the needs of a procedure on a form. I do
understand that FN's return a single value.

I'm wondering, is this a good place to employ a user-defined Type?

The FN would reside in a global module. When called, it does return
one value considered to be the most important. But while it's running,
it does calculate several more important values that would otherwise
have to be REcalculated in the calling function when processing
returns there. Comments?

[Allen Browne]

The simplest approach is to pass some extra arguments *into* the function,
and set them in there. The calling routine can then check the value of those
variables afterwards.

A user-defined type is also a good solution for some cases. See:
Multiple return values from a Function - User-defined types
at:
http://allenbrowne.com/ser-16.html

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"MLH" <CR**@NorthState.netwrote in message
news:1a********************************@4ax.com...

>I would like to call a function that "returned" several values - all
of which are relevant to the needs of a procedure on a form. I do
understand that FN's return a single value.

I'm wondering, is this a good place to employ a user-defined Type?

The FN would reside in a global module. When called, it does return
one value considered to be the most important. But while it's running,
it does calculate several more important values that would otherwise
have to be REcalculated in the calling function when processing
returns there. Comments?

[lyle fairfield]

MLH <CR**@NorthState.netwrote in
news:1a********************************@4ax.com:

I would like to call a function that "returned" several values - all
of which are relevant to the needs of a procedure on a form. I do
understand that FN's return a single value.

I'm wondering, is this a good place to employ a user-defined Type?

The FN would reside in a global module. When called, it does return
one value considered to be the most important. But while it's running,
it does calculate several more important values that would otherwise
have to be REcalculated in the calling function when processing
returns there. Comments?

Public Function MyHeroes(ByVal p1, ByVal p2) As Variant
Dim a(6) As Variant
a(0) = UCase(p1)
a(1) = LCase(p1)
a(2) = StrConv(p1, vbProperCase)
a(3) = UCase(p2)
a(4) = LCase(p2)
a(5) = StrConv(p2, vbProperCase)
MyHeroes = a
End Function

Sub test()
Dim r As Variant
r = MyHeroes("giLbert a HIGHet", "harry s Truman")
Debug.Print r(0)
Debug.Print r(1)
Debug.Print r(2)
Debug.Print r(3)
Debug.Print r(4)
Debug.Print r(5)

'GILBERT A HIGHET
'gilbert a highet
'Gilbert A Highet
'HARRY S TRUMAN
'harry s truman
'Harry S Truman

End Sub

--
lyle fairfield

[MLH]

Thanks, Allen. In the simplest case, where only a single argument is
required for the function to do its job, there would be no need to
pass the FN additional info that would be superflous. But with that
single input, the FN may make a considerable number value assignments
along the way whilst it's doing its job. When done, it returns a
single and hopefully useful value to the calling procedure. What would
the addtional inputs do to reach the desired end?

>The simplest approach is to pass some extra arguments *into* the function,
and set them in there. The calling routine can then check the value of those
variables afterwards.

[MLH]

Oops. I might have err'd...
I assumed that a(6) was a variant array. But a small
addition to your code did not verify that...

Public Function MyHeroes(ByVal p1, ByVal p2) As Variant
Dim a(6) As Variant
a(0) = UCase(p1)
a(1) = LCase(p1)
a(2) = StrConv(p1, vbProperCase)
a(3) = UCase(p2)
a(4) = LCase(p2)
a(5) = StrConv(p2, vbProperCase)
MyHeroes = a
Debug.Print ".......", VarType(a), "......."

End Function

Sub test()
Dim r As Variant
r = MyHeroes("giLbert a HIGHet", "harry s Truman")
Debug.Print r(0)
Debug.Print r(1)
Debug.Print r(2)
Debug.Print r(3)
Debug.Print r(4)
Debug.Print r(5)

'....... 8204 .......
'GILBERT A HIGHET
'gilbert a highet
'Gilbert A Highet
'HARRY S TRUMAN
'harry s truman
'Harry S Truman

End Sub

I would have expected a value of 8192 - but that sure ain't
what I got. Hmmm???

[MLH]

Looks like its part vbVariant and vbArray
when evaluating the value returned in a
bitwise manner. Surely that's it. I mean, its
certainly not a UDT.

[lyle]

On Oct 22, 1:05 pm, MLH <[e-mail]:

Oops. I might have err'd...
I assumed that a(6) was a variant array. But a small
addition to your code did not verify that...

Public Function MyHeroes(ByVal p1, ByVal p2) As Variant
Dim a(6) As Variant
a(0) = UCase(p1)
a(1) = LCase(p1)
a(2) = StrConv(p1, vbProperCase)
a(3) = UCase(p2)
a(4) = LCase(p2)
a(5) = StrConv(p2, vbProperCase)
MyHeroes = a
Debug.Print ".......", VarType(a), "......."

End Function

Sub test()
Dim r As Variant
r = MyHeroes("giLbert a HIGHet", "harry s Truman")
Debug.Print r(0)
Debug.Print r(1)
Debug.Print r(2)
Debug.Print r(3)
Debug.Print r(4)
Debug.Print r(5)

'....... 8204 .......
'GILBERT A HIGHET
'gilbert a highet
'Gilbert A Highet
'HARRY S TRUMAN
'harry s truman
'Harry S Truman

End Sub

I would have expected a value of 8192 - but that sure ain't
what I got. Hmmm???

TTBOMK 8192 is never returned from VarType.

One hopes that you got 8204.

8192 indicates an array; 12 indicates a variant. 8192 +12=8204,

TypeName(a) returns Variant(), that is, variant array.

[Allen Browne]

You can make the arguments Optional, so you don't have to pass them all.

You can pass a ParamArray(), where the number of arguments will vary at
runtime.

You can pass a Recordset, which contains all the fields as values.

You can use a user-defined type, with a structure that's akin to a
recordset.

Horses for courses.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"MLH" <CR**@NorthState.netwrote in message
news:7r********************************@4ax.com...

Thanks, Allen. In the simplest case, where only a single argument is
required for the function to do its job, there would be no need to
pass the FN additional info that would be superflous. But with that
single input, the FN may make a considerable number value assignments
along the way whilst it's doing its job. When done, it returns a
single and hopefully useful value to the calling procedure. What would
the addtional inputs do to reach the desired end?

>>The simplest approach is to pass some extra arguments *into* the function,
and set them in there. The calling routine can then check the value of
those
variables afterwards.

[MLH]

OK. Many thx.

[MLH]

Gotcha. I later noticed the last paragraph
in HELP indicated exactly what you said.

[MLH]

OK. Thx.