Passing parameters between forms in MS Access

I have created a login form 开发者_StackOverflownamed login where the username is typed into the txtEmployee textbox, and I need to display the same in the second page in another form in MS Access.

---

DoCmd.OpenForm allows you to pass an arbitrary value as the last parameter. This value can be accessed in the new form as Me.OpenArgs:

' Invoked by some Button on the first form '
Sub GoToSecondPage()
    DoCmd.OpenForm "MySecondPage", acNormal, , , , , txtEmployee.Value
End Sub

' Second form '
Sub Form_Open(Cancel As Integer)
    If Not IsNull(Me.OpenArgs) Then
        lblShowEmployeeName.Value = Me.OpenArgs
    End If
End Sub

(Code example untested.)

---

You can pass a delimited string as the OpenArgs parameter:

DoCmd.OpenForm FormName:="miscForm", OpenArgs:=paramstring

Here's a routine for processing a pipe-delimited string passed as the parameter to DoCmd.OpenForm:

Dim Pstring As Variant

If Len(Me.OpenArgs) > 0 Then
   Pstring = Split(Me.OpenArgs, "|")
   var1 = Pstring(0)
   <etc..>
End If

---

Personally I would pass them through the open arguments when opening the form. For example from form A your would write

DoCmd.OpenForm "frmB", , , , , acDialog,”Badger”

And then in the OnOpen event of form B you can capture what you have sent like this

Me.txtSomething=Me.OpenArgs

You can only pass one thing however What I do a lot is pass a pipe delimited string in the open arguments and then split that out.

---

A couple ideas...

Use the AfterUpdate event on the login username field to write the name to a global variable, then populate the field on the second page with the OnLoad event.

Or, if you plan on leaving the log in form open at all times you could set the default value of the field directly to =[Forms]![LogInForm]![UserName]

---

Why not create a public function which stores &/or retrieves a global variable that you store after the first form is executed? This would allow you to not only use it on one or more forms, but also as criteria within a query (for example, to return records which match the user name you've stored).

I agree this is "fake" security, but there also times when it's sufficient for your needs. I've implemented this before, where I match the environment string username to an entry in a user table.

BTW, I refer to this feature as personalization, not security.

Just a thought.