Return a value from Userform.Show()?

[Robert Crandal]

I have been relying heavily on global variables to return
a value (or values) from any Userform in my program.
Is this the only way to return a value from Userform.Show()?

Is it possible to try something like:

x = Userform.Show() ' ???

This might work for returning one value, but what if I
had multiple values to return from a userform?

Just curious what other options are available, because I
feel like the global variable method is not always very
efficient.

Thanks!

 

[Harald Staff]

One way, probably the best, is building a class where the userform is a part
of its dataset. I don't know how comfortable you are with classes.

So an easier faster way is this: On top of the userform module, create some
public variables, like

Public S as string
Public L as long
'as many as you need

Code for its OK button:

Private Sub CommandButton1_Click()
Me.S = Me.Textbox1.text
Me.L = Me.Combobox1.Listindex
Me.Hide
End Sub

Code for its cancel button:

Private Sub CommandButton2_Click()
Me.S = "cancelled"
Me.Hide
End Sub


And finally, main code i a standard module:

Sub Test
Dim UF as Userform1
Dim X as String, Y as Long
Set UF = New Userform1
Uf.Show
X = UF.S
Y = UF.L
Unload UF
If X = "cancelled" then
'something sad?
Else
Msgbox "You wrote " & X
End if
End Sub

HTH. Best wishes Harald

 

[GS]

I have been relying heavily on global variables to return

a value (or values) from any Userform in my program.
Is this the only way to return a value from Userform.Show()?

Is it possible to try something like:

x = Userform.Show() ' ???

This might work for returning one value, but what if I
had multiple values to return from a userform?

Just curious what other options are available, because I
feel like the global variable method is not always very
efficient.

Thanks!

Global variables are pretty much common in most programming languages.
Managing them efficiently, though, requires simple common sense gained
from experience. The beauty of using 'globals' is that they can be
accessed from anywhere at anytime, by any procedure.

Implementing an 'InitGlobals' procedure that runs at startup is a good
place to start. This will 'load' all the 'startup values' your project
needs at runtime. These values can be stored (registry or text file)
for retrieval when your project starts, OR they can be set at startup
(or anytime during runtime).

If using the Registry for storage, "SaveSettings()" and "GetSettings"
are the main VB[A] functions to use when the default hive for the HKCU
key suffices for your needs. Beyond that there's several Registry API
functions you can use to work anywhere within the Registry the current
user has UAC permissions to access for writing. I stopped using the
Registry some years ago when I made all my projects completely reg-free
so they can be run from a memstick on any machine without leaving
anything behind.

There's a number of ways to store startup/runtime values in text files,
all which depend on how the data is structured. The most common methods
employ using INI and DAT files for storing startup values, program
options, and user preferences.

INI files is what Windows used before the Registry was introduced.
These are structured plain text files that require using the
PrivateProfile APIs to use them.

DAT files are also plain text files, but their contents are in binary
format. The VB[A] functions used for this are "Put()" and "Get()", and
the data is stored in UDTs.

IMO the only downside of using globals is we need to be careful of
'overuse'! Otherwise, using globals are a very neat and efficient way
to manage 'shared' runtime data.<g>

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion