Re: "Return Value" for a form?

From: Dirk Goldgar (dg_at_NOdataSPAMgnostics.com)
Date: 02/07/05 

Date: Mon, 7 Feb 2005 12:53:14 -0500

"Joe Holzhauer" <joedvm@sbcglobal.net> wrote in message
news:xyNNd.2086$ng6.1664@newssvr17.news.prodigy.com
> 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

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)