VB6 passes string value from one form to another

The key is that you need a way in Form2 to Reference Form1.  One way to do this is to have a property (or subroutine) that allows you to pass to Form2 a reference to Form1.

The example code below requires a Form1 and a Form2.  Each should have a command button by the name "Comman1", and Form1 needs a label by the name "Label1".  In the code, when you click Command1 in Form1, it will create an instance of Form2, set a reference of Form1 in Form2 and display Form2 modally.  When Command1 is clicked in Form2, it will set the Caption of Label1 in Form1 and then unload itself.

'Form1(Code)
Private Sub Command1_Click()
Dim F as Form2
  Set F = New Form2
  Set F.Form1Reference = Me
  Call F.Show(vbModal)
End Sub

'Form2(Code)
Private m_Form1 as Form1
Public Property Set Form1Reference(F as Form1)
  Set m_Form1 = F
End Property
Private Sub Command1_Click()
  m_Form1.Label1.Caption = "Form2 Set the Caption"
  Unload Me
End Sub

Select allOpen in new window

Alternatively you could define strString1 as a Public variable, i.e. "Public strString1 As String".  That way Form2 could fill it in and Form1 (or any other form in your application) could use the variable's value.  

Follow up Notes:

The code above assumes 'Form1' is the Startup Object.  You could also have 'Sub Main' as the Startup Object.  If so, then you would need to add a model file and include the following code in there:
Public Sub Main()
Dim F as Form1
  Set F = New Form1
  F.Show(vbModal)
End Sub

VB6 does something a bit wierd (in my opinion) that can easily confuse newbies.  VB automatically creates a global object for each Form defined in the project.  The name of this global object is the name of the Form.  When us use "Form1" as the startup object, VB loads this global Form1 object and displays it modally.  The project will also have a global Form2 object (not yet loaded).  You load Form2 by either explicately loading it with the Load Command, or simply call Form2.Show(vbModal),  That will automatically Load the global Form2 and display it modally.  If you only want to work with the global objects, then you can use VBClassicGuy's suggestion, because that code will operate on the global Form1 object.  If you want multiple instance of the various forms, then you have to create these other instances of the forms and maintain reference to which form you want to do what to.

I just tested my simple answer and it works fine.

@VBClassicGuy,

Yes, the simple answer works just fine... IF you are using the global Form1 object.  

But if you create a new instance of the form (Form1 in this instance) and display that form, then the 'simple' answer will fail, because it will act against the global Form1, not the new instance of Form1 being displayed.

To see what I'm talking about, set the startup object to Sub Main.  Then add the following code in a module (.bas file) and run the application.

Public Sub Main()
Dim F as Form1
    Set F = new Form1
    F.Show vbModal
End Sub

The form object visible is the F object defined in Main(), not the Global Form1 object that remains hidden.  Execute 'Form1.Label1.Caption="XYZ"' and you will see that the caption of the displayed form does not update.

@HooKooDooKu, that makes sense if the project calls for that method.  For me, when I can get away with it, I go for simple like VBClassicGuy's answer, maybe global vars (for small apps) or even properties.  Given the limited info in the question, simple is a good place to start.  

The nice thing about setting a form variable as you suggested is that it has lots of flexibility for changing the scoping of the form variable, but does it take more memory to do so than a string var?  I'm not certain.  Maybe that doesn't matter.

Just felt I should make a comment on this thread. After submitting my solotion, I was the only responder. I left the page open, and went to test the solution, as I couldn't think if I had ever done this with one form being modal. After the test, I posted my comment that it worked.

In the meantime, others responded, but I didn't see these other responses until I later got an email and looked at the question. The order in which the responses were posted might have made it look like I was slamming other responses as too complicated. This was definately NOT my intention. The answers given by HooKooDooKu and others are great solutions for the scenarios described, and I salute them on their ingenuity.

I apologize if it looked any other way to anyone.