Function vs. Sub

  • Thread starter Thread starter terry w
  • Start date Start date
T

terry w

Sorry if this is a newbie question:

Why do I need both Subs and Functions. I know that Functions return a value
while Subs do not. Instead of using a Sub, is it possible to just use a
Function but not either ignore or not define its return value. What is the
actual advantage in using a Sub when the return value is not needed?

Regards
Terrance
 
Terrance:

Great question. You may get a variety of responses, but here's what
I've found, and what I believe.

1) You can use Subs if nothing is returned, but I seldom do.
2) Always describe a return value for a function, even if it's not used.

Why?

In previous versions of Access, you couldn't use a Public Sub as the
source for events on property pages. For example, if you have a routine
that validates entry in general, and you want to apply it to many controls
on their AfterUpdate event, you could set it to this text ...

=ValidateMyInput()

But that failed if it was a public SUB instead of a FUNCTION. That's been
corrected in newer version, I think, but I'm still used to using functions.

Also, as for always returning something, it's just a picky bit. If you don't
specify any data type as a return value, a Variant is used. So this ...

Public Function ValidateMyInput() As Boolean

is less memory intensive than this ...

Public Function ValidateMyInput()
 
terry w said:
Sorry if this is a newbie question:

Why do I need both Subs and Functions. I know that Functions return a
value
while Subs do not. Instead of using a Sub, is it possible to just use a
Function but not either ignore or not define its return value. What is
the
actual advantage in using a Sub when the return value is not needed?

Regards
Terrance
Click to expand...

The only advantage (if you can call it one) is that it's obvious when you
read your code that the routine doesn't return a value. Otherwise there's no
technical advantage to either. Personally I always use functions whether I
want to return a value or not. Purely habit.
 
A function returns a value, a sub does not. A function can be used by a query
(this is a major advantage!).
I'm not aware of any advantage to either if a return value is not needed.
Yes you can use a function and ignore the return value.
You should look up Sub and Function in Access HELP system.
-- Dorian
"Give someone a fish and they eat for a day; teach someone to fish and they
eat for a lifetime".
 
The answer to your question is a piece of history of the BASIC language.
Subs (subroutines) were originally a way to break a procedure up into
smaller, reusable parts. Functions were a way to perform a calculation and
return a value.

You can certainly use a Function for everything, never creating your own Sub
if you wish. There are some advantages to this approach, e.g. functions can
be called from more places (e.g. directly in the property of a control.)
There is generally something you can assign as the return value (even if
it's little more than a success/fail flag), but even that's not essential.
You then have the flexibility to examine or ignore the return value.

For example, you might create a function that opens a form and returns True
if it succeeded or False if an error occurred. This is much more functional
than the DoCmd.OpenForm that can throw error 2501 or other errors, so you
code:
Public Function OpenTheForm(strForm As String) As Boolean
On Error Resume Next
DoCmd.OpenForm strForm
OpenTheForm = (Err.Number = 0)
End Function
Now if you want to know whether the form opened before you continue, you
code:
If OpenTheForm("Form1") Then
'do something with the form
End If
or if you don't need to take further action, you code:
Call OpenTheForm("Form1")

Of couse, the event procedures in Access are Subs, so you will still be
calling subs too.
 
Dorian:

I hate to pick on you, but you opened the door to a pet peeve of mine.
I don't think it's good ettiquete to ever answer a newsgroup post of
any kind with the suggestion, "Look it up in the help file"

There was a time when help files were useful, but those days ended
about 4 years ago. Now, search SQL Server On Line Books for
something like CHARINDEX and you get millions of bits of information,
but nothing useful or useable.

The same is more-or-less true of Access help system. I still keep a
copy of Access 97 around, just so I can access the help file to get a
direct answer to my questions.

But even if that wasn't true, it should be assumed that people who post
to newsgroups are looking for something more than the cold, impersonal
and sometimes incomplete information they can find in a help file.

Whew. Feels good to get that off my chest. And FWIW, it's not something
I've seen in the Access newsgroups so much. It's more in the SQL Server
group. Someone will ask something like ...

"How do I format a date in SQL Server as YYYY-MM-DD?"

Someone will then reply, read the help file under CONVERT(). The help
file text for the CONVERT() method sucks. Actually, the help file sucks
because SQL Server sucks when it comes to handling dates. (Sorry
Aaron, but if you can't admit that, then we know you have blinders on.)
The Access Format() function still a dream for SQL Server.

There's a trick to that little date format, something not mentioned in the
help file. No one on the SQL Server newsgroups ever helped me with
it and it wasn't until I'd been using SQL Server for 7 years before I learnt it.


BTW, the SQL Server trick I'm speaking of is that date formats only work
if/when you convert them to strings. The top 3 SQL calls below all return
the same output. The bottom two give you different formats. Of course,
those calls won't give you any custom formats, like YYYYMMDD without
punctuation. You'll have to add function calls for that, and if you want single
digit month and day to be padded with zeros then you need an army of
functions.
SELECT GETDATE()
SELECT CONVERT(DATETIME, GETDATE(), 101)
SELECT CONVERT(DATETIME, GETDATE(), 1)

SELECT CONVERT(VARCHAR(11), GETDATE(), 101)
SELECT CONVERT(VARCHAR(11), GETDATE(), 1)

Sometimes, it's not enough to read the help files. That's why people support
newsgroups like this one.
 
I disagree completely.
I have found the Help files to be an invaluable source of information.
There is far more there than can be repeated here.
The help files are also one of the most underutilized reasources.
Learning to use Help is like teaching someone to walk instead of giving them
a set of crutches.
-- Dorian
"Give someone a fish and they eat for a day; teach someone to fish and they
eat for a lifetime".
 
Back
Top