"Return Value" for a form?

  • Thread starter Thread starter Joe Holzhauer
  • Start date Start date
J

Joe Holzhauer

I've run into this problem several times, and it's fairly easy to work
around, but it seems like there's a better way. I even asked the question
in this forum but I don't think I was clear about what I was asking.

Basically, is there a better way for a popup form to return a value to the
calling form than referring to a text box on the calling form? For example:

I've written a form that asks a user to enter a client ID. Most of the
time, they have the client ID available and can just type it in...
sometimes, though, the user needs to be able to search for the client (by
name, partial ID, or some combination of other traits).

My solution is to allow the user to click a search button, which brings up a
query-by-form interface. The user can then enter the search criteria and
select the appropriate client. This is all fine, but now here's the
question:

What I've always done in the past is stored the client ID for the client
they selected in a text box on the main form. i.e.:

Forms![frmMainForm].txtClientID = lstClientID

This seems awkward to me. You have to check that the main form is open
before you can return it, and then what happens if you want to use your
popup from a different form also?

So, is there a way to have the popup form "return" a value to whatever form
called it? i.e.:

txtClientID = frmPopup

(I know that won't work, but it's what I want to emulate.)

Sorry for going on and on...

Thanks in advance!
Joe
 
Joe Holzhauer said:
I've run into this problem several times, and it's fairly easy to work
around, but it seems like there's a better way. I even asked the
question in this forum but I don't think I was clear about what I was
asking.

Basically, is there a better way for a popup form to return a value
to the calling form than referring to a text box on the calling form?
For example:

I've written a form that asks a user to enter a client ID. Most of
the time, they have the client ID available and can just type it in...
sometimes, though, the user needs to be able to search for the client
(by name, partial ID, or some combination of other traits).

My solution is to allow the user to click a search button, which
brings up a query-by-form interface. The user can then enter the
search criteria and select the appropriate client. This is all fine,
but now here's the question:

What I've always done in the past is stored the client ID for the
client they selected in a text box on the main form. i.e.:

Forms![frmMainForm].txtClientID = lstClientID

This seems awkward to me. You have to check that the main form is
open before you can return it, and then what happens if you want to
use your popup from a different form also?

So, is there a way to have the popup form "return" a value to
whatever form called it? i.e.:

txtClientID = frmPopup

(I know that won't work, but it's what I want to emulate.)

Sorry for going on and on...

Thanks in advance!
Joe
Click to expand...

I can think of two other approaches offhand.

The simplest, though somewhat fragile, approach is to define a global
variable (a Public variable declared at module level in a standard
module) to hold the selected ClientID. Then your popup form would stick
the chosen ID (or Null if none was chosen) in that variable, and the
calling code would get it from there, and then immediately reset the
variable to Null. This method is fragile because unhandled errors can
cause the VB project to be reset, forcing global variables to lose their
values, and also because the variable is accessible -- and modifiable --
from various locations, so it's conceivably possible for it to get
mangled between the call to the popup form and the extraction of the
value from the variable. However, if you carefully circumscribe the use
and implement good error-handling, you can limit your exposure to such
problems to an acceptable level.

A more complicated but less fragile way is to have the popup form
(opened in dialog mode) make itself invisible when the user has chosen a
ClientID. That allows the code in the calling procedure to proceed, at
which point the calling procedure can extract the ClientID from the
popup form itself, and then close the form. You can wrap this in a
function that returns the ClientID, or Null if none was chosen.

'----- start of example code -----
Function fncChooseClient() As Variant

' *** add your error-handling ***

DoCmd.OpenForm "frmChooseClient", _
WindowMode:=acDialog

If CurrentProject.AllForms("frmChooseClient").IsLoaded Then
fncChooseClient = Forms("frmChooseClient")!lstClientID
DoCmd.Close acForm, "frmChooseClient", acSaveNo
Else
fncChooseClient = Null
End If

End Function
'----- end of example code -----
 
Thank you for the expert advice, Dirk. Those are both excellent solutions.


Dirk Goldgar said:
Joe Holzhauer said:
I've run into this problem several times, and it's fairly easy to work
around, but it seems like there's a better way. I even asked the
question in this forum but I don't think I was clear about what I was
asking.

Basically, is there a better way for a popup form to return a value
to the calling form than referring to a text box on the calling form?
For example:

I've written a form that asks a user to enter a client ID. Most of
the time, they have the client ID available and can just type it in...
sometimes, though, the user needs to be able to search for the client
(by name, partial ID, or some combination of other traits).

My solution is to allow the user to click a search button, which
brings up a query-by-form interface. The user can then enter the
search criteria and select the appropriate client. This is all fine,
but now here's the question:

What I've always done in the past is stored the client ID for the
client they selected in a text box on the main form. i.e.:

Forms![frmMainForm].txtClientID = lstClientID

This seems awkward to me. You have to check that the main form is
open before you can return it, and then what happens if you want to
use your popup from a different form also?

So, is there a way to have the popup form "return" a value to
whatever form called it? i.e.:

txtClientID = frmPopup

(I know that won't work, but it's what I want to emulate.)

Sorry for going on and on...

Thanks in advance!
Joe
Click to expand...

I can think of two other approaches offhand.

The simplest, though somewhat fragile, approach is to define a global
variable (a Public variable declared at module level in a standard
module) to hold the selected ClientID. Then your popup form would stick
the chosen ID (or Null if none was chosen) in that variable, and the
calling code would get it from there, and then immediately reset the
variable to Null. This method is fragile because unhandled errors can
cause the VB project to be reset, forcing global variables to lose their
values, and also because the variable is accessible -- and modifiable --
from various locations, so it's conceivably possible for it to get
mangled between the call to the popup form and the extraction of the
value from the variable. However, if you carefully circumscribe the use
and implement good error-handling, you can limit your exposure to such
problems to an acceptable level.

A more complicated but less fragile way is to have the popup form
(opened in dialog mode) make itself invisible when the user has chosen a
ClientID. That allows the code in the calling procedure to proceed, at
which point the calling procedure can extract the ClientID from the
popup form itself, and then close the form. You can wrap this in a
function that returns the ClientID, or Null if none was chosen.

'----- start of example code -----
Function fncChooseClient() As Variant

' *** add your error-handling ***

DoCmd.OpenForm "frmChooseClient", _
WindowMode:=acDialog

If CurrentProject.AllForms("frmChooseClient").IsLoaded Then
fncChooseClient = Forms("frmChooseClient")!lstClientID
DoCmd.Close acForm, "frmChooseClient", acSaveNo
Else
fncChooseClient = Null
End If

End Function
'----- end of example code -----

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)
Click to expand...
 
Back
Top