AB submitted this idea :
The reason i do it this way (and - as per the code - i terminate the
form and don't keep it in memory longer than necessary) is otherwise
there is way big of a chance (for me anyway) that the global variables
would have retained the value from previous user entry and not the
current one - as that's the whole point - you give it a value, it
keeps it as long as in compile state.
But when a code grabs that public varialbe - how would it know whether
that is an entry that the user typed into the form just now or 60mins
ago? To manage that aspect strict controls need to be in place and i
find the
form.hide
read control value
unload form
method more convenient and safer especially it's not such a big of a
drag onto the pc's memory anyway.
Just my 0.02 of worth.

You cite a good point. This is precisely why I used a function to load
the userform. That function clears any previous values in the vars
before it opens the userform, ensuring that any values in the vars will
be new to the current input.

Note that I suggest the input values should be validated by the
userform. This is so the userform purpose can be encapsulated and thus
reusable. The procedure that processes the data doesn't need (nor
shouldn't IMO) to know anything about how the data was collected in
order to do its task, which only happens if the function was
successful. This, in turn, depends on what happens in the userform as
far as validation of input goes OR if the user cancels. Again, this
should be handled in the userform.

<FWIW
Seems that popular opinion regarding userforms that collect data/input
is that the userform should handle all validations and where the valid
data goes. Our procedures that use/process the data should not be
'tied' to the userform in any way.

Otherwise, wouldn't InputBox suffice?

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc