Passing Variables Between Subs

If the forms are in the same project, then declare the variable as Public in one of the form's General Declaration sections.  This will allow the variable to be global in scope.

:>)

Should have mentioned that a good practice is to have a module that contains global variables.  This allows sharing of variables between forms, classes and modules.  You should always declare global variables in the General Declarations section as follows:

Public g_strMyStringVariable as String

In doing this your entire project my now access this variable!

Oops, one last item.  If you decide to delcare the variable as global within one of the forms, say the form name is frmSecondForm and the variable name is strStringValue you will call it in the other form as follows:

frmSecondForm.strStringValue

Otherwise if you declare the variable in a module you only need to use:

strStringValue

Sorry for allow the comments, want to make sure I don't forget something!
:>)

If you need to do something depending on what the value might be a better solution than using the Public varname As vartype is using a private variable and two public properties. Like this...

Private m_Something As String

Public Property Let Something(New_Value As String)

  m_Something = New_Value

End Property

Public Property Get Something() As String

  Something = m_Something

End Property


If you add this code to the form you can set the variable using code like...

  formname.Something = "Test"

This will call the Public Property Let Something (..) procedure.

I would accept VBMaster's solution.  This is the proper way to pass variables between objects in a project!
:>)

HeyHey ... I won't be that sure about this ...

There's another (IMHO better-to-understand) solution.

In Form2 (the called form) add the following

dim mParam as string

Public Sub ShowWithData(byval ThisString as string)
    mParam = thisString
    ' do some processing
    me.show
End Sub

In Form1 you do the following instead of the old Form2.Show

Sub command1_click()
    form2.showwithdata "Hello World!"
end sub

Yet another choice.
Every form has an unused property called
Tag, which is available to you.
So, in form 1 you could say

Form2.Tag = "Hello Form 2"

And when you get to form 2 lo if you read Tag it will say Hello Form 2.

vbmaster solution follows the rules of variable encapsulation. a much better way of programming i think we will all agree.

Yes I agree with vbmaster also.  Using public properties like he described, not only do you follow the rules like TheFly stated, but you get  MUCH cleaner looking code, you get the ability to pass more than one var to the form (as opposed to using the "Tag" method of 3rsrichard), and when you go back to the project a month or two later, you can trace to flow of the program much easier than if you were to use global variables.  I just thought I'd back up vbmaster :).

- Tom

Tag is encapsulated, Microsoft encapsulated it at the factory.

Brian is welcome to follow the ways of OOP, but why stop with m_Something .
Wheres his business case, his UML diagram.  
Brian doesn't need to be doing simple things just because he's a beginner,  methodology is a lot more important than results!!

I don't really agree with theFly (or vbmaster) as I think the encapsulation of my example is higher.

If you have f.e. a form that displays a list of invoices. Say you want to query them by dateFrom, dateTo and customer-number.

In vbMasters example you'd have to do

form1.datefrom = #1/1/2000#
form1.dateto = #1/10/2000#
form1.customernr = 1234
form1.show

whereas you could also do

form1.showList #1/1/2000#,#1/10/2000#,1234

if showlist is like
public sub showlist(byval dateFrom as date, byval dateTo as date, byval CustNo as long)


even better when you'd like to have the user select a value you could simply do it like:


(declarations of form)
dim mSelectedInvoiceNr as Long

public Function getInvoiceNr(byval dateFrom as date, byval dateTo as date, byval CustNo as long) as long
   ' initialize the grid with the data
   ' ....

   me.show vbmodal
   if mSelectedInvoiceNr = 0 then
       getInvoiceNr = 0
       unload me
       err.raise vbobjecterror + 123,,"No Invoice selected"
   else
        getInvoiceNr = mSelectedInvoiceNr
        unload me
   end if
end function

sub cmdSelect_Click()
    mSelected = <get the current number somehow>
    me.hide
end sub

sub cmdCancel_Click()
    mSelected = 0
    me.hide
end sub


you could then call it like

    myNr = form1.getInvoiceNr(...)


I think that this is even more encapsulated.

(this code wasn't checked, but it should show my point of view)


Cheers,
Ingo

Are you guys trying to make Brians life miserable?
He didn't ask you how to build a computer, just where to put in the quarter to start it.  Can anyone come up with a method more convoluted?

lenlutz: I know it may sound crazy but around here we (who's this we I keep hearing about?) use the answer feature when we have something to add. ;)

hmmm ... i think lenlutz just said what I did several lines above ;)

yes rammeri.... you are correct.... (i must have missed it)

Whats this "use answer feature" ?

Please expalin that ?
thanks

lenlutz: he's talking about the "propose an answer"-option when posting a feedback (instead of using a comment) ;)

ingo

at the bottom of the page,i see:



                       1.Have a comment for BrianMaslowski?

                       2.Or you could withdraw your proposed answer, and make it a comment

                         Comment  (with an option button)
                         Withdraw Answer   (with an option button)

i see nothing that looks like:
                         propose an answer

lenlutz
It's hard to tell if you are being intentionally obtuse or not.
When you submitted your answer there were two button choices Answer or Comment.
VB was suggesting that since your answer was just a rehash of of what rammeri had already said it might be considered unfair to claim it was an answer.
Of the two choices you now see at the bottom of the page the one you have obviously found lets you make a further comment.  The one you haven't tried is the one you should choose.

Oh, and if you were being intentionally rude then you were much to subtle about it, nobody got the point.