i am completely new to VB. with some help i have created a userform with some command buttons on it & i have also inserted a Combobox with drop down option from the same worksheet but different workbook.the dropdowm options are basically states of the US.

now i want to input an excel in the userform, that should populate data from a worksheet in the same workbook.

based on the state selection in the dropdown of the combobox, in the excel sheet i need to populate the data related to that particular state from column A to Column BI

i am not able to get an excel sheet in the user form, and please let me know how do i get it related to the dropdown option.

Any help would be greatly appreciated.

Thanks in advance.

After setting up his example, I followed breakpoints throughout execution of the program and plotted 12 steps that occur starting with the “Set F = New frmValuePass” and ending with “Set F = Nothing” and suddenly the light came on. I sketched it out on paper and then applied same structure to my own code & form and within an hour had accomplished what I’d struggled with for about 2 days.

My problem seemed to be figuring out how to load up a listbox of a form prior to showing the form but where the listbox’s “AddItem” logic needed some passed arguments from my main sub in order to know what to add to the listbox, and needed other passed arguments to be merely displayed on the form once shown (text box, labels, etc.). I kept trying to figure out how to use a form’s “initialize” routine to invoke the ListBox logic, which was of course way too soon IF one needs to 1st pass several arguments to the form’s environment.

Just in case someone else reading thru this is struggling as I was with the issue of passing multiple arguments to a form via properties (the “recommended” method) prior to the form’s execution, I’ll try to enunciate the key points that were eluding me, a 1st-time form-with- listbox user (some of this is spelled out in Erik’s self-documented code):

[This will all make much more sense if you code up Erik's example -- including every single one of his embedded comments -- and then set breakpoints at everything in the controlling sub and everything in the form's property routines and subs and then monitor the code as it executes. You can read his comments during breakpoint pauses and make your own notes and likely not even bother with anything else I have to say below.]

1) It helped when I categorized the “sequential events” in 3 visual columns:
a) Sub events (controlling sub)
b) Form Properties & Form Sub events
c) Form itself
The “sequential events” will zig-zag from column-to-column during execution

2) The form doesn’t really require an “initialize” routine prior to passing it some property values. As Erik pointed out, mere instantiation is enough in the sub’s “Set F = New frmValuePass” statement. Turns out I didn’t need to execute “ListBox AddItem” logic until immediately prior to the “Show” command.

3) The sub’s invoking of a specific property’s “Let” routine in the form module will regain control of events immediately after the “Let” routine is executed. i.e., the controlling sub’s “F.Value1 = 8? invokes the corresponding “Let” routine in the form module at which point control returns to the sub. And realize that this can be done repeatedly as many times as needed by the controlling sub (hence multiple arguments passed to the form).

4) Realization that by using the “Let” properties to “hold” the passed argument in a separately-named argument, the named argument (and not the property name itself) is where the passed argument will be made available later down the road in your form’s logic –WITHOUT a requirement to use a GET routine. i.e., “gValue1 = TheValue” in Erik’s “Let Value1? routine stages the passed argument in “gValue1? which demonstrates ‘persistence’ within the form’s environment as long as the form remains ‘loaded’.

5) Realization that from my controlling sub I could invoke a named “form sub” by merely referencing it by name as if the name were a form’s “property”. In Erik’s example, he used “F.Display” in his controlling sub to invoke the form’s “Public Sub Display()” routine. I didn’t know I could do that. It enabled me to put into my own project’s “F.Display” routine a call to my ListBox logic residing in yet a separate sub also behind the form.

6) And of course, the final objective in my case was to have my controlling sub obtain knowledge of the selected listbox item. And the key there is to not unload the form quite yet when you’re finished with listbox item selection but merely hide it for a few more seconds until control passes from form back to your controlling routine at which point you invoke one final request of the form environment — the “Get Result” property in Erik’s example, where “Result” merely equates itself to any of the previously-used named values from the form routines (txbResult in Erik’s example).

In summary, the light that came on for me was the realization that I could separately pass named property arguments from my controlling routine to the form as many times as necessary prior to invoking a form routine that could subsequently execute additional “form” logic (e.g., find specific data values from a table and load them into the listbox contents) while making use of the previously-passed arguments to help in that effort, and then actually show the form.

Hope that helps. And a Huge Thank You to Erik!

Sub FormVariablePassingExample()
Dim F As frmValuePass ‘just creates a variable, doesn’t instantiate anything
Set F = New frmValuePass ‘instantiates the form, but because it’s hidden, code execution continues
F.Value1 = 8 ‘set some values
F.Value2 = 6
‘You don’t have to have one property per value. You could use an array. Or a publicly defined
‘ type (like a C structure: Type TypeName // Variables // End Type.
‘ or an object. Or a delimited string. Whatever.

F.Display ‘This is a custom method on the form which gets it ready and does the .show
‘You could use .show directly, but I used this method to give the form a chance
‘ to know I was done passing values in so it could do some setup.
‘Code execution suspends here until the form is hidden (becomes invisible) again.
‘Clicking OK on the form makes the form hide, thereby resuming code execution.

Debug.Print F.Result ‘we can look at the form or get values out to our heart’s content
‘Note that the value printed out is whatever was in the textbox when you clicked close.
‘It’s good practice to use something like this Result property instead of examining the
‘ textbox directly. What if you change how your form functions or does its job? Better
‘ to observe the “Law of Demeter” and only use properly defined interfaces to the form’s
‘ data, instead of depending on knowing details about what’s inside the form.

Set F = Nothing ‘now actually unload the form, by removing all references to it.
End Sub

‘ Next, create a new form called frmValuePass
‘ give it any caption you like.
‘ Add a textbox and name it txbResult
‘ Add a button called btnOK and make it the Default button
‘ Add the following code:
‘—————

Option Explicit

Private gValue1 As Long
Private gValue2 As Long

Public Property Let Value1(TheValue As Long)
gValue1 = TheValue
End Property

Public Property Let Value2(TheValue As Long)
gValue2 = TheValue
End Property

Public Sub Display()
txbResult = gValue1 * gValue2
Me.Show
End Sub

Public Property Get Result() As Long
Result = Val(txbResult)
End Property

Private Sub btnOK_Click()
Me.Hide
End Sub

A small example:

*** workbook ***
Private Sub Workbook_Open()
Dim i As Integer, i2 As Integer
Dim bWksExists As Boolean
i2 = Worksheets.Count
For i = 1 To i2
If Worksheets(i).Name = “wksMyVars” Then
bWksExists = True
End If
Next i
If Not bWksExists Then
Worksheets.Add After:=Worksheets(i2)
With Worksheets(i2 + 1)
.Name = “wksMyVars”
.Visible = xlHidden
End With
End If
End Sub

*** In a module ***
Sub ShowForm()
With Worksheets(“wksMyVars”)
.Range(“A1?).Value = “Greeting”
.Range(“B1?).Value = “Hello World”
End With
‘ (A1 is set to Greeting for readability of the worksheet itself)
UserForm1.Show
End Sub

*** UserForm1.CommandButton1 ***
Private Sub CommandButton1_Click()
Dim sGreeting As String
sGreeting = Worksheets(“wksMyVars”).Range(“B1?).Value
MsgBox sGreeting
End Sub

Rembo

The “official” way to do this, which isn’t much different than what you’re doing, is to use a property procedure in the user form (or other class module). Then use a userform.show command in the calling procedure. There are property let (or set) procedures to assign values to a form’s property, and property get procedures to retrieve these properties from a form. I’ve written a short article on the topic:

http://peltiertech.com/Excel/PropertyProcedures.html

- Jon
—–
Jon Peltier, Microsoft Excel MVP
Peltier Technical Services
Tutorials and Custom Solutions
http://PeltierTech.com/
_______

******************** Userform1 *******************
Option Explicit
Dim LocalVar as String

Private Sub UserForm_Initialize()
‘ Initialization code here
End Sub

Sub MyVariable (ByVal MyVal as String)
LocalVar = MyVal
Userform1.Show
End Sub

**************************************************

To pass the variable to the Userform I call it with:

Sub MainPgrm()
Dim MyVal as String
MyVal = “Some text”

Userform1.MyVariable MyVal

End Sub

The call first executes the “Private Sub UserForm_Initialize()”. It then goes to the “MyVariable” sub routine where the value is assigned to a local variable. If you don’t precede the call to MyVariable with Userform1 it doesn’t work. Is there a reason I should not pass variables to a userform this way?

This could be a post/thread in itself. The basic answer is that you need to add a Get statement and then access it as a property of the class like you would any other class/control/form (e.g. frmEmployees.Caption, frmEmployees.txtLastName.Text, or clsEmployee.LastName).