Why is using GoTo considered bad practice?

I know but doesn't user-defined type reset because of an un-handled error?
 
No, it doesn't hold any value.

In the example, the variables of the UDT are defined locally (ie the return value of function EmpWNIS() and Dim TN As TableNIS in the Test() sub)
 
@gemma-the-husky
How about this : You have 3 returning values from one function.

Code:
Sub test()
    Dim Param1 As Date
    Dim Param2 As String
    Dim Param3 As Integer
 
    Param1 = Date
    Param1 = MyFunction(Param1, Param2, Param3)
    Debug.Print Param1
    Debug.Print Param2
    Debug.Print Param3
End Sub

Public Function MyFunction(Param1, Optional ByRef Param2, Optional ByRef Param3) As Date
        Param2 = "Kita Yama"
        Param3 = 100
        MyFunction = DateAdd("d", 1, Param1)     
End Function

Yes - I know how to do it, it just feels slightly wrong when I use arguments as byRef
 
Last edited:
Thanks for that link David. I have all sorts of links re ChrisO. He certainly knew the intricacies and had examples to try and teach the rest of us.
 
David,
I noticed that the sample database on that latest link can not be downloaded. It appears to be a feature not yet available?? It would be nice to have some of the ChrisO gems/sample dbs available in newer version of Access.
 
searching Chris's stuff is both nostalgic and extremely educational!
ChrisO was long gone by the time I came around, but it is obvious to the most casual observer that he was a tremendous asset and a real Access Heavyweight.
 
I know but doesn't user-defined type reset because of an un-handled error?
That does not make sense at all. In an unhandled error all variables reset throughout the application. So in your example all those variables reset too. Only tempvars do not.
 
ChrisO was a member here(AWF) also. Many posts with great discussion, comments and examples are here and searchable..
 
Yes - I now how to do it, it just feels slightly wrong when I use arguments as byRef
I think most people feel this way. Almost never see people modify a passed variable in a sub, although it is completely legitimate. I find it hard to debug and follow the logic. When i do this accidently it can make your head spin debugging. My guess is that is why VB now defaults to byval.
 
David,
I noticed that the sample database on that latest link can not be downloaded. It appears to be a feature not yet available?? It would be nice to have some of the ChrisO gems/sample dbs available in newer version of Access.
I was able to download it.

It was in A97 format so I have converted it to A2K7, so modern versions should be able to open it.

Might be a bit of a mission to convert all his samples! Let me know if you find any specific ones I can do quickly. (y)
 

Attachments

Thanks David. I downloaded your attachment successfully.

Speaking of nostalgia, you can just see ChrisO saying this (taken from his comments in your attached file).

'* No restrictions! *
'* Please do not use this until you know how it works. *
'* (That goes for homework as well, your teacher might ask.)



This is the error message I got when trying to download the A97 file from UA.
ErrorA97_UA.PNG
 
Last edited:
I think most people feel this way. Almost never see people modify a passed variable in a sub, although it is completely legitimate. I find it hard to debug and follow the logic. When i do this accidently it can make your head spin debugging. My guess is that is why VB now defaults to byval.
so does that mean anyone building VB aps has to check all the code when recompiling?
 
so does that mean anyone building VB aps has to check all the code when recompiling?
I do not understand the question. The default is simply byval. Not sure what that has to do with recompiling.
 
I do not understand the question. The default is simply byval. Not sure what that has to do with recompiling.

you said VB now defaults to byVal. That implies there's old code that doesn't explicitly say byVal, and works byRef. So if you edit the old code, and recompile the old code in the new compiler, than the (undeclared) byRef arguments will now become byVal, so programs that worked great in vbOLd now produce strange results in vbNew, because arguments passed to subs now don't return different values.

That would happen in Access if VBA code that we use suddenly treated all default arguments (currently byRef) as (now the new default) byVal.
 

Users who are viewing this thread

Back
Top Bottom