Re: "Return Value" for a form?

From: Joe Holzhauer (joedvm_at_sbcglobal.net)
Date: 02/07/05 

Date: Mon, 07 Feb 2005 18:05:38 GMT

Thank you for the expert advice, Dirk. Those are both excellent solutions.

"Dirk Goldgar" <dg@NOdataSPAMgnostics.com> wrote in message
news:%23VVBE3TDFHA.1564@TK2MSFTNGP09.phx.gbl...
> "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)
>
>