private types - overhead if retrieved seperately?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Jesper F - 07 Jan 2006 15:52 GMT

I recently found out about returning several values from a function using a
private type like:

Private Type ABresult
A as string
B as integer
End Type

Function GetInfo() as ABresult
...
GetInfo.A = xx
GetInfo.B = yy
End function

This is very cool. However, if I'm using GetInfo.A and .B somewhere wouldn't
I be calling the GetInfo()-function twice?
If I'm using the values of GetInfo.A and GetInfo.B in the same procedure
somewhere, it seems to eliminate overhead if I have the GetInfo-function
return a string such as "yy;xx" instead and then parse my way to get yy and
xx.
Should the use of private types be reserved for situations where you need
either A og B and not both in conjunction since I'd be running the function
twice and creating overhead?
Thanks for any input.

Jesper Fjølner

Reply to this Message

Marshall Barton - 07 Jan 2006 18:04 GMT

>I recently found out about returning several values from a function using a
>private type like:
[quoted text clipped - 19 lines]
>either A og B and not both in conjunction since I'd be running the function
>twice and creating overhead?

If you want to use a type like that, you should declare a
variable in the calling procedure to hold the function's
return value(s):

Dim MyInfo As ABresult
MyInfo = GetInfo
If MyInfo.A = x then
y = MyInfo.B
. . .

OTOH, for more elaborate situations you may want to explore
using a Class module instead of a user defined type.

Signature

Marsh
MVP [MS Access]

Reply to this Message

Tim Ferguson - 07 Jan 2006 18:23 GMT

> This is very cool. However, if I'm using GetInfo.A and .B somewhere
> wouldn't I be calling the GetInfo()-function twice?

If you mean as in this:

MyA = GetInfo().A
MyB = GetInfo().B

then yes, that's two calls. An alternative would be

With GetInfo()
MyA = .A
MyB = .B
End With

which _probably_ only calls the thing once but I wouldn't trust later
versions of VBA not to change its mind.

> If I'm using the values of GetInfo.A and GetInfo.B in the same
> procedure somewhere, it seems to eliminate overhead if I have the
> GetInfo-function return a string such as "yy;xx" instead and then
> parse my way to get yy and xx.

Very nasty. Very sixties. Nearly as bad as using globals.

> Should the use of private types be reserved for situations where you
> need either A og B and not both in conjunction since I'd be running
> the function twice and creating overhead?

There are plenty of proper modular ways of doing this;

Dim res as MyType

set res = GetInfo
' actually, I would do this with a With res structure
MyA = res.A
MyB = res.B

or more simply again, change the function to a sub

' using byref arguments to pass back more than one value
public sub GetInfo(ByRef A as Sometype, B as SomeObject)
A = something
set b = new somethingelse
end sub

dim MyA as sometype
dim MyB as someobject
getinfo(myA, myB)

The other approach would be to use a proper class

dim someInfo as New MyInfoClass
with someInfo
.GetInfo()
MyA = .A
MyB = .B
End with

Hope that helps

Tim F

Reply to this Message

John Nurick - 07 Jan 2006 22:41 GMT

> With GetInfo()
> MyA = .A
[quoted text clipped - 3 lines]
>which _probably_ only calls the thing once but I wouldn't trust later
>versions of VBA not to change its mind.

Experiment seems to show that the function is indeed only called once
per With block:

Function GetInfo() As MyType
Static j As Integer

j = j + 1
GetInfo.A = j
GetInfo.B = j
End Function

--
John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.

Reply to this Message

Jesper F - 08 Jan 2006 10:50 GMT

> There are plenty of proper modular ways of doing this;
> The other approach would be to use a proper class
[quoted text clipped - 5 lines]
> MyB = .B
> End with

Thanks for alle the answers. I'm using classes much, but I do use a lot of
functions with several arguments.
I think it difficult to leverage my programming into use classes more and
there're aren'nt many tutorials around about this.

A lot of time it seems to me that a task is just as easily accomplished
using a function with a handful of arguments as it would be to make a
class - set 5 properties and run a method.
I'm thinking of buying the Access 2002 Developer Handbooks - will I find
anyting about class building in those?

Thanks.

Reply to this Message

Tim Ferguson - 08 Jan 2006 18:54 GMT

"Jesper F" <askfortheemail@ask.com> wrote in news:eU2REFEFGHA.1088
@tk2msftngp13.phx.gbl:

> A lot of time it seems to me that a task is just as easily accomplished
> using a function with a handful of arguments as it would be to make a
> class - set 5 properties and run a method.

The use of classes is more about debugging and maintenance than being
"easily accomplished": what looks a doddle one weekend is a month of
headaches six months later when someone else has to upgrade/ debug/ alter
it. Still: that is where the craft of programming takes over from the
science, and is what keeps most of us going!

> I'm thinking of buying the Access 2002 Developer Handbooks - will I find
> anyting about class building in those?

The series has an excellent reputation and deservedly so; but how long are
you going to be using Access 2002?

All the best

Tim F

Reply to this Message

Jesper F - 09 Jan 2006 00:35 GMT

>> A lot of time it seems to me that a task is just as easily accomplished
>> using a function with a handful of arguments as it would be to make a
[quoted text clipped - 5 lines]
> it. Still: that is where the craft of programming takes over from the
> science, and is what keeps most of us going!

Ok, I'll think about that. I'll agree that my multi-argument-functions would
be easier to work with later if converted to classes.

>> I'm thinking of buying the Access 2002 Developer Handbooks - will I find
>> anyting about class building in those?
> The series has an excellent reputation and deservedly so; but how long are
> you going to be using Access 2002?

Well, from what I'm hearing about Access12 - quite some time :-)
Just kidding. I hope learn something new from the books, but may pass them
on within not too long if I'm upgrading.

Jesper

Reply to this Message

Jesper F - 09 Jan 2006 01:09 GMT

> The use of classes is more about debugging and maintenance than being
> "easily accomplished": what looks a doddle one weekend is a month of
> headaches six months later when someone else has to upgrade/ debug/ alter
> it. Still: that is where the craft of programming takes over from the
> science, and is what keeps most of us going!

On more question. Am I correct in thinking of classes as a way to do
something like:

mycls.propA=this
mycls.propB=that
mycls.propC=more

and then towards the end of the procedure use:

msgbox mycls.bigprop

where the bigprop is a procedure in the class that calculates and returns
stuff for example.
So classes are always initialized and ended within the same procedure in the
application?
Can the "hold" their values and be used in other procedures?

Jesper

Reply to this Message

Tim Ferguson - 09 Jan 2006 17:20 GMT

> and then towards the end of the procedure use:
>
> msgbox mycls.bigprop

Yes.

> where the bigprop is a procedure

strictly speaking, it's a method (!)

> in the class that calculates and returns stuff for example.

or, even better, do

myCls.DescribeYourself

so that the calling routine doesn't even have to know that the class has
a string representation.

> So classes are always initialized and ended within the same procedure
> in the application? Can the "hold" their values and be used in other
> procedures?

Remember: the Class is an empty template and does not have any life of
its own whatever. When you call one into existence using Dim or New or
whatever, then it's an Object that is referred to by a Variable (think of
the Class of DAO.Database or Excel.Application or whatever). The scope of
object variables obeys the same rules as all other variables: they can be
Global or Public or Private; passed into routines as arguments or
returned as values from Functions; ad so on.

It's one of those things that is easier to do than to describe!

All the best

Tim F

Reply to this Message

Jesper F - 09 Jan 2006 19:59 GMT

> Remember: the Class is an empty template and does not have any life of
> its own whatever. When you call one into existence using Dim or New or
[quoted text clipped - 4 lines]
> returned as values from Functions; ad so on.
> It's one of those things that is easier to do than to describe!

All right, Thanks again. I'll start using it more and the concept will sink
in better I hope.
Cheers.

Jesper

Reply to this Message