Returning text from Userdefined Functions

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello!

I have a user defined function to write data back to a database in my Excel
sheet. I return a smal text to show the user if the function was successful
or not. When I set the return value of the function in regular code, it works
fine. But, when something goes wrong, the execution goes to an error handler,
the function does not return the string I set anymore.

I have the code:


Public Function WriteData()
on error goto ErrorHandler

..
..
calculations
..
..

WriteData = "OK" 'This is returned correct to the
cell

goto End

ErrorHandler:

WriteData = "Not OK" 'This returns #VALUE to the cell

End:

End Function


Can someone tell me the reason of this behavior, and/or what I am doing wrong?

Regards DagL
 
This is the cell where the function is called from. Sometimes the string is
returned correct, but when the code has been in an error handler, the cell
displays "#VALUE!"
 
Hi

Because the error handler is called from the UDF it is subject to the same
limitations as the UDF so if there's an error in the called routine you
aren't notified and simply get the VALUE error in the cell. Check out the
error handler it sounds very much like the error is within that.

Mike
 
I have looked into this, but does not see any difference. The error is not
happening in an called routine, it is inside the UDF. I have an erorr handler
paragraph that calls an central error handler function. The return string
from the central error handler function is set to bee the return value of the
UDF. I tried not to call the central error handler function, and have a
simple error handler paragraph within the UDF, but the same result is
happening.

I have the error handler inside the UDF, and as soon as the execution goes
into this, the return from the UDF is wrong. When the code runs without
error, the return string is correct. See the code example I wrote in my first
post. My problem is actually as simple as this show. If the execution enters
the error handler paragraph, the UDF does not return what I set it to do.

Regards DagL
 
VBA won't allow me to use the statement goto End, which doesn't surprise me.
If I change goto End to goto EndIt and change End: to EndIt: then the
function seems to work fine. James
 
I have looked at this, the "Break on Unhandled Errors " is the chosen
radiobutton

Regards DagL
 
Actually, the paragraph that I named "End:" is in my original program
"Slutt:". This is because I wrote the example code in english terms, since
this is an english spoken community.

I have also tried not to use the line "Goto Slutt" in my error handler
paragraph, since the execution goes into this paragraph anyway. This has no
effect on my problem

Regards DagL
 
If you insert a line like

Debug.print "Error handler has run..."

right at the end of your error handler (just before the line containing
the "Slutt:" label) and then recalculate the sheet, does the message
show up in the intermediate window in VBE?
 
I have now inserted the line you mentioned, and I can report that it is
written to the immediate window.

Regards DagL
 
If you copy following code into a module of a new workbook with just one
worksheet and insert =Test() into a cell... does that give the VALUE
error as well?

Public Function Test() As String
On Error GoTo ERR_HANDLER
Test = ThisWorkbook.Sheets(2).Name
GoTo UDF_END
ERR_HANDLER:
Test = "#GRMPF#"
UDF_END:
End Function

In your code, after the "Slutt:" label, there's nothing more than the
"End Function" statement, right?
 
Your code in a new workbook does not give the VALUE error. The return value
of this is what was expected, #GRMPF#

Actually, my Slutt: paragraph does have code. The code is to close down a
recordset that I have used in the code. I did not think this was of interest,
since both error situations and correct situations went through the code.

My Slutt: paragraph looks like this:

Slutt:
' clean up
If rs.State = adStateOpen Then
rs.Close
End If



I now tried to remove the code in the Slutt: paragraph, and then it worked!
But, does this mean that I cannot close my recordset after an error?


Regards DagL
 
As far as I know the error handling section should always be the last
part of a procedure. Once a runtime error has occurred and the the code
jumped to an error handler label, no more errors are raised! It looks
like the code would work.

I think you'll have to restructure your code to achieve what you want.
 
Check in VBE: Tools / Options / General / Break on Unhandled Errors

As a general rule, you should choose "Break In Class Module", not "Break On
Unhandled Errors". This difference becomes clear when you have an error in
an object module. Suppose you have a UserForm with code like:

Private Sub UserForm_Initialize()
Me.Label1.Caption = CStr(1 / 0) ' Error
End Sub

an a code module with code like

Sub ShowTheForm()
UserForm1.Show
End Sub

If you have the error trapping set to "Break On Unhandled Errors", you 'll
set a run time error on the line of code

UserForm1.Show

But there really isn't an error with the Show method. However, if you set
error trapping to "Break In Class Module", you'll get an error on the
correct line of code:
Me.Label1.Caption = CStr(1 / 0)

If you didn't know the difference in error handling modes, you could spend a
lot a valuable time trying to figure out what is wrong with the Show method.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel, 10 Years
Pearson Software Consulting
www.cpearson.com
(email on the web site)
 
Chip, That's fantastic. Wish I had know about this years ago. Sure would
have made learning userforms easier. Would it be reasonable, after fixing
any errors in the userforms (so that Userform1.Show doesn't error out), to
set it back to "Break on Unhandled Errors"?
James
 
Would it be reasonable, after fixing
any errors in the userforms (so that Userform1.Show doesn't error out), to
set it back to "Break on Unhandled Errors"?
Click to expand...

I wouldn't. No matter how fully one tests code, any non-trivial code can
blow up under some unforeseen (and untested) circumstance, no matter how
remote. I would leave error handling at "break in class" for easy debugging
down the road. There is no reason to change it back to "unhandled errors".


--
Cordially,
Chip Pearson
Microsoft MVP - Excel, 10 Years
Pearson Software Consulting
www.cpearson.com
(email on the web site)
 
Okay. Thank you, Chip.

Chip Pearson said:
I wouldn't. No matter how fully one tests code, any non-trivial code can
blow up under some unforeseen (and untested) circumstance, no matter how
remote. I would leave error handling at "break in class" for easy
debugging down the road. There is no reason to change it back to
"unhandled errors".


--
Cordially,
Chip Pearson
Microsoft MVP - Excel, 10 Years
Pearson Software Consulting
www.cpearson.com
(email on the web site)
Click to expand...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

write to range object using vb.net 2
lastrow function help 6
Error: Method 'open' of object 'IXMLHTTPRequest' failed 4
Return to starting point 1
Return the Module Location & Sub Procedure Name on Error 7
Runtime error 1004 write data to a cell 9
VBA Countif across sheets? 5
Return the Line Number where the Error Occured 5

Back
Top