Pass variable between forms

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

When a user wants to delete a record on a form, I open another form to ask
for a password. How do I pass the confirmation back to the main form to be
able to delete the record?
 
hi Dean,
When a user wants to delete a record on a form, I open another form to ask
for a password. How do I pass the confirmation back to the main form to be
able to delete the record?
Click to expand...
You need a global variable or property to hold the information.


mfG
--> stefan <--
 
Dean,

The way I do it is to open the second form in dialog mode. This suspends
processing of the code on the main form.

Then, when the user clicks the command button to close the 2nd form, I set
its visible property to False, but don't actually close it. The advantage of
this is that by setting the visible property to false, the code in the main
form will resume processing. At that point, you can check the value of
controls on the second form with a syntax similiar to:

Forms!yourForm2.txtPassword

Once you have processed that, you need to remember to close the 2nd form.

docmd.close acform, "yourForm2"

HTH
Dale
 
Let's call the form where you want to delete a record frmUpdateTables and the
form to get the password frmPassWord.

First, Open frmPassWord in Dialog mode. Here is an example from one of my
apps:
DoCmd.OpenForm "frmPassWord", acNormal, , , , acDialog
If Me.txtPwd = "Cancel" Then
MsgBox "Updates Canceled"
ApplyUpdates = False
Exit Function
End If

Note the reference to Me.txtPwd. It is an invisible control on
frmUpdateTables.

Now, in frmPassWord, you could use the text box After Upate to do this, but
in this case, I used a command button.

Private Sub cmdOk_Click()
Forms!frmupdatetables!txtPwd = Me.txtPwd
DoCmd.Close acForm, Me.Name, acSaveNo
End Sub

I also have a cancel command button if I want to cancel the operation and
close the form

Forms!frmupdatetables!txtPwd = "Cancel"
DoCmd.Close acForm, Me.Name, acSaveNo


The above code populates the invisible control in frmUpdateTables with the
value entered by the user then closes frmPassWord.

Now the code in frmUpdateTables continues on the line
If Me.txtPwd = "Cancel" Then
 
Albert,

I notice in your solution and in Dale's, you make the dialog form go
invisible then retrieve the data from the original form. What is your
reasoning for doing it that way?
My technique is to pass the data from the dialog to hidden controls on the
original form. If your solution has advantages over mine, I would be
interested in knowing what they might be.

Thanks,
 
Klatuu said:
Albert,

I notice in your solution and in Dale's, you make the dialog form go
invisible then retrieve the data from the original form. What is your
reasoning for doing it that way?
My technique is to pass the data from the dialog to hidden controls on the
original form. If your solution has advantages over mine, I would be
interested in knowing what they might be.

Thanks,
Click to expand...

I think my approach is more "old" style thinking. the advantage of my
approach is that you can build a routine to get a date.

eg::


dtMyStartDate = MyGetDate()

The function MyGetDate can launch the form, get he user input, and then
return the value. so, I might not be wanting to return values to fields or
properties of the form, but simply prompt the user with a nice custom date
form, or some type of form to grab some type of input (perhaps a prompt for
the users initials to run a danger process).

Further, it means for each form, or code that I want to re-use this prompt
form, I don't have to create those hidden controls.

I talk about this advantage here:

http://www.members.shaw.ca/AlbertKallal/Articles/PickSql/Pick4.html

However, that article was written about 6-7 years ago. And, right now, I am
reframing from using dialog forms. While they allow re-use of forms, they
break the windows interface (you can't use the menu bar for example).


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(e-mail address removed)
 
Back
Top