[AccessD] Function vs Sub

Henry Simpson hsimpson88 at hotmail.com
Thu Feb 13 16:41:00 CST 2003


Both Subs and Functions can be private or public.  The question asks about 
the difference between functions and public subs.  With regard to the scope 
issue, there is no difference.

A function 'can' return a value and does if a return type is specified, 
whether or not a value is assigned to the return by the function:

Function fnctnTest() As Boolean

is set up in the declaration to return a boolean.  If code never runs to set 
the value to either true or false, the implicit return is false.

Function fnctnTest()

looks like a sub without a return.  It returns nothing, even though it could 
have been made to do so.  No implict false in this.  It simply operates 
identically to a sub.

Sub subTest()

with the same code behind it as fnctnTest will operate identically to 
fnctnTest, also without the implicit return.

Sub subTest(Parameter1, Parameter1, Parameter3)

is a sub that receives three arguments.  If these arguments are passed by 
reference (the default unless otherwise explicitly stated), then any 
modification of the paramters is effectively returned to the calling 
procedure.  If in fact you were working with three string parameters and 
wanted to do the same thing with a function, you could write the function, 
without explicit data typing mind you, either of the following two ways:

Function fnctnTest(Parameter1, Parameter2, Parameter3) As String

or

Function fnctnTest(Parameter1, Parameter2, Parameter3)

If you were only operating on a single parameter, the function could return 
a value in the same way a sub does, always assuming 'By Ref' and with data 
typing:

Function fnctnTest(Parameter1 As String)

is the same as

Function fnctnTest(Parameter1 As String) As String

and is the same as

Sub subTest(Parameter1 As String)

In all three cases, the procedure can modify and effectively 'return' 
Parameter1.

One of the more important differences between subs and functions in the 
realm of Access programming is where or how you can call them.  A calculated 
value in a query won't work as a sub because it must use a returned value 
and you must use a function.  The autoexec macro can execute a function but 
not a sub and you can use function names in the event procedure property 
sheet of a control or form but can not use a sub.  By definition, callback 
functions must be based on functions.  Once you sort out if and when 
parentheses are required in calling the procedures, you can pretty much use 
either for any other functionality.

For example, if you wanted to use a Sub in John's example of a function:

Sub BldReport(blnIn As Boolean)
On Error goto BldReport_Error
	blnIn = false	'Specify a false value up front.  The process must work
to be set true
	Do my report process, try to store etc.
	.
	.
	blnIn = true
Exit_BlDReport
	Exit Sub
Err_BldReport
	'handle errors here
	resume Exit_BldReport
End Sub


Hen




>From: "John W. Colby" <jcolby at colbyconsulting.com>
>Reply-To: accessd at databaseadvisors.com
>To: <accessd at databaseadvisors.com>
>Subject: RE: [AccessD] Function vs Sub
>Date: Thu, 13 Feb 2003 12:09:08 -0500
>
>John,
>
>Functions can return a value, subs can't.  It is often useful when you move
>to this method of programming to return a value that says that the function
>accomplished it's purpose.  IOW, perhaps the function is supposed to build 
>a
>report.  The report is going to (in this example) be saved as a hardcopy on
>the network somewhere.  There are all kinds of things that could prevent 
>the
>report from being generated, or being saved.  So the function returns a 
>True
>if the report process worked, or a false if it didn't.
>
>I tend to do something like:
>
>function BldReport() as Boolean
>On Error goto BldReport_Error
>	BldReport = false	'Specify a false value up front.  The process must work
>to be set true
>	Do my report process, try to store etc.
>	.
>	.
>	BldReport = true
>Exit_BlDReport
>	Exit function
>Err_BldReport
>	'handle errors here
>	resume Exit_BldReport
>end function
>
>As you might surmise, the function tries to build the report.  If anything
>goes wrong the error causes control to vector to the error handler where
>whatever you decide to do to handle errors is done.  When it is done,
>control resumes at the exit.  The statement that sets the function name 
>true
>is never executed, so the function returns false.
>
>If no error occurs, processing just continues down the function and
>eventually sets the function return value true and exits.
>
>Therefore the code that tries to generate the report can now do something
>like:
>
>	if BldReport() then
>		'This is good, continue
>	else
>		'this is bad, notify the user, log the error etc.
>	endif
>
>So, to re-iterate, functions can return a value.  Even if they normally
>wouldn't it is often useful to use that ability to return the fact that the
>function succeeded in whatever it was supposed to do.
>
>John W. Colby
>Colby Consulting
>www.ColbyConsulting.com
>
>-----Original Message-----
>From: accessd-admin at databaseadvisors.com
>[mailto:accessd-admin at databaseadvisors.com]On Behalf Of John Clark
>Sent: Thursday, February 13, 2003 11:20 AM
>To: accessd at databaseadvisors.com
>Subject: [AccessD] Function vs Sub
>
>
>I recently smartened up and started using fuctions in my code, and I've
>got what may be a very dumb question...should I be using "functions" or
>should they be "Public Subs" or ?????? What is the difference. I
>apologize if I am lowering the intelligence quota today, but I just
>haven't come across this and I don't want to go down the wrong path.


_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*   
http://join.msn.com/?page=features/junkmail




More information about the AccessD mailing list