Return a value from a form opened as acDialog

[David H]

I know that we can pass values to a form view the OpenArgs parameter of the
OpenForm object, but is there a way to inherently pass values back (other
than capturing the value in a global value or unbound box)?

I'm thinking NO, but believe it or not, I've never had to do that until today.

 

[Jim Burke in Novi]

Funny, I was just wanting to do the same thing earlier today (and have wanted
to do this several times over the years ). I'm pretty sure there's no way to
simply have the form return a value (I wish Microsoft would create a function
that would do it!). What I do is create a 'global' public variable that will
have the value I need returned, then in the 'called' form's close event (or
somewhere in the form module), set the variable to the appropriate value. The
form needs to be defined as a popup form for this to work, so that your VB
code will call the form, then continue to the next statement after the
'called' form closes. I typically create a function which simply opens the
form,then sets the function value to the value I want returned from the form.

e.g. I want variable 'x' to have the returned value, form frmReturn is the
form that will 'return' the value, public 'global' variable 'gl' will contain
the value set by the form. So in a module somewhere I would have

public gl as Integer (or whatever type is needed)

Public Function GetFormValue() as Integer (matches type of above variable)

DoCmd.OpenForm "frmReturn", , , , , acDialog
GetFormValue = gl

End Function

somewhere in frmReturn I would have code that sets the value of gl, which
represents the value that the form is 'returning'. Then when I want to open
the form and retrieve the 'returned' value I would have

x = GetFormValue

 

[Marshall Barton]

I know that we can pass values to a form view the OpenArgs parameter of the
OpenForm object, but is there a way to inherently pass values back (other
than capturing the value in a global value or unbound box)?

I'm thinking NO, but believe it or not, I've never had to do that until today.

You're thinking correctly.

The "usual" way is for the dialog form to make itself
invisible instead of closing. Then the calling code can
retrieve the value of a text box and close the form.

 

[David H]

I thought the answer was no. On one hand it makes since because MS would have
to create a property to capture the return value which would have to be set
via code in order for OpenForm() to operate as a function.

Oh well. Global variable it is then.

 

[Rick Brandt]

I thought the answer was no. On one hand it makes since because MS would
have to create a property to capture the return value which would have
to be set via code in order for OpenForm() to operate as a function.

Oh well. Global variable it is then.

Did you read what Marshall suggested (below). That is very simple and
much better than a global variable.

 

[David H]

Obviously if the form is left open, the value is still available until you're
done with it. But why not use a global variable?

 

[dymondjack]

I think golbal variables in general are viewed as flukey, as they tend to
reset themselves for no real reason. I use the global variable method as
well (I keep a public var for each datatype for exactly this purpose).
Speaking from experience, it gets to be a little confusing at times if
there's a lot of places you intend to do this. Most of what I use it for is
a popup search form, but I've often wondered about too many things going on
at once and the globals being read wrong. As a rule, I always set them back
to default or into a more appropriately scoped variable as soon as the
requirement for a global is up.

To get around the confusion of making sure that the same var will never be
used by different forms at the same time, you could always name seperate
global vars with different names for each place you want to use it, but that
becomes a lot of overhead memory for something that shouldn't need it.

After reading Marshal's solution, I had to stop and think about it for a
minute. But, I can see where his would be desirable... I've used these
'globals' in various projects for a few years now, and haven't run into any
issues yet, but hiding the form and closing it from the caller seems a bit
cleaner. I'll have to keep it in mind myself for future work.

--
Jack Leach
www.tristatemachine.com

- "First, get your information. Then, you can distort it at your leisure."
- Mark Twain

 

[Marshall Barton]

I think golbal variables in general are viewed as flukey, as they tend to
reset themselves for no real reason. I use the global variable method as
well (I keep a public var for each datatype for exactly this purpose).
Speaking from experience, it gets to be a little confusing at times if
there's a lot of places you intend to do this. Most of what I use it for is
a popup search form, but I've often wondered about too many things going on
at once and the globals being read wrong. As a rule, I always set them back
to default or into a more appropriately scoped variable as soon as the
requirement for a global is up.

To get around the confusion of making sure that the same var will never be
used by different forms at the same time, you could always name seperate
global vars with different names for each place you want to use it, but that
becomes a lot of overhead memory for something that shouldn't need it.

Nice summary. I wouldn't have said it as well.