Passing a variable back from a sub

[RonL]

Pardon the extremely novice question. I want to retrieve the value of a variable sent to a subroutine in the "general" code section of a form back to the calling code which is a form event procedure. I'm finding variables set in the sub are out of scope back in the form event code (or in the immediate window, for that matter, after the sub ends). I know how to assign the variable using a function, but I want to do it in a sub, since I'll be setting more than one variable there. What's the proper way to do this?



Thanks, Ron

[June7]

The variable is still available in the main routine even after the subroutine runs. Code after the subroutine call should still be able to use the variable. If you want to reference the variable after the main routine terminates then declare global variable or populate textbox.

[RonL]

The variable is still available in the main routine even after the subroutine runs. Code after the subroutine call should still be able to use the variable. ........

Thanks for the quick response. I must be doing something else wrong then, because in the following, triggered by clicking on the form (and just thematic for testing purposes), the first Msgbox (to fire) gives the correct values for both variables, but the second (to fire, ie. after return from the Sub) gives nothing and the watch list confirms the variable is not defined after return to the calling sub. What am I missing? Something to do with option statements perhaps?

Private Sub Form_Click()
Dim varshotnumber As Integer
'Dim var2shotnumber As Integer <==should not be needed, 'cause variable is declared in the sub, right?
varshotnumber = 45
Call rklMakeShotNumber("NoInsert", varshotnumber, "b")
MsgBox (var2shotnumber)
End Sub

''''''''''''
****the following is in the general section of the form code, though I'd also tried it from a separate module*******

Public Sub rklMakeShotNumber(rklMode As String, curShotNumber As Integer, curShotNumSuffix As Variant) <== (This last variable is for other purposes.)
' Public var2shotnumber As Integer <== BTW, this statement generates an error on the use of "Public" . How come?
Dim var2ShotNumSuffix As Integer

Select Case rklMode

Case "NoInsert"

var2shotnumber = curShotNumber + 1
MsgBox ("from general code section" & curShotNumber & var2shotnumber)
Case "Insert"
....other code
End Select
End Sub

[stmoong]

A few points to note.

1) A public variable is declared in the module (or form), not within a subroutine or function.

2) In general, try to avoid using public variables if possible because they make code maintenance difficult.

3) If you want to change the value of a variable within a subroutine and have it accessible by the calling function, then you can use the keyword ByRef. Something like this:

Private Sub Form_Click()
    Dim intShotNumber As Integer
    intShotNumber = 45
    rklMakeShotNumber "NoInsert", intShotNumber, "b"
    MsgBox intShotNumber
End Sub

'Place this in the form code if it is not called by other forms or modules
Private Sub rklMakeShotNumber(ByVal rklMode As String, ByRef curShotNumber As Integer, ByVal curShotNumSuffix As Variant)
    Select Case rklMode
        Case "NoInsert"
            curShotNumber = curShotNumber + 1
        Case "Insert"
            ....other code
        Case Else
            MsgBox "Unknown rklMode = " & rklMode
    End Select
End Sub

[June7]

RonL, Click code calls subroutine with varshotnumber but MsgBox uses var2shotnumber. var2shotnumber is declared as local variable in the subroutine and therefore is not available to the Click event.

Should have this line at the top of every module:
Option Explicit

I agree with stmoong. Global and Public variables are a pain when debugging. I use them sparingly. I probably could revise some code to take advantage of the ByRef method.

[RonL]

RonL, Click code calls subroutine with varshotnumber but MsgBox uses var2shotnumber. var2shotnumber is declared as local variable in the subroutine and therefore is not available to the Click event.

Thanks June, I had interpreted your first comment to mean that it shouldn't matter, that the variable would still be available to the calling routine. But from Stmoong's post, I realize now I was putting the declarations in the wrong place. Doh.

1) A public variable is declared in the module (or form), not within a subroutine or function.

That was the problem, even keeping them as private variables. Scope was screwed up because I had the declarations in the wrong place apparently. Thanks Stmoong.

So I don't need public variables after all. But I will take your other advice into account as well.

Incidentally, these variables are just standins for control values. Trying to get comfortable with data flow before messing with the underlying table (even though it's got only dummy data at this point.) The goal for one case of the select, at least, is to take data from the current record, modify it and update a new record with the modifications. I'm familiar with the recordset object and the DoCmd gotoRecord, but not intimately, and not enough to even understand when one is preferred over the other. So I try approaches that seem simplest based on (long ago) experience with other languages.

Many thanks to both of you.

Ron

[June7]

Glad you got it figured out in spite of my comment. I had assumed you were talking about a variable that was declared in the main procedure. Stmoong really did clarify nicely.

[stmoong]

Glad to help.