private types - overhead if retrieved seperately?

  • Thread starter Thread starter Jesper F
  • Start date Start date
J

Jesper F

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
 
Jesper said:
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?
Click to expand...


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.
 
This is very cool. However, if I'm using GetInfo.A and .B somewhere
wouldn't I be calling the GetInfo()-function twice?
Click to expand...

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.
Click to expand...

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?
Click to expand...

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
 
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.
Click to expand...

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
 
There are plenty of proper modular ways of doing this;
The other approach would be to use a proper class

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


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.
 
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.
Click to expand...

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?
Click to expand...

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
 
A lot of time it seems to me that a task is just as easily accomplished
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!
Click to expand...

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.
The series has an excellent reputation and deservedly so; but how long are
you going to be using Access 2002?
Click to expand...

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
 
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!
Click to expand...

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
 
and then towards the end of the procedure use:

msgbox mycls.bigprop
Yes.

where the bigprop is a procedure
Click to expand...

strictly speaking, it's a method (!)
in the class that calculates and returns stuff for example.
Click to expand...

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?
Click to expand...

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
 
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!
Click to expand...

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

Jesper
 
Back
Top