OpenArgs - passing text depending on what button was presses

[Danick]

I have a command button on a form that open a second form and use OpenArgs to pass the ID that was in the first form.

Is it possible to have multiple command buttons on the first form that will open the second form as before, but insert predetermined text (not parameters from first form) in certain fields of the second form?

For instance, there is a text field on the second form that the user will type either "Chat" or "email" or "Call". So instead of having 3 separate forms that will populate that field on load, I'd like to have three buttons that will populate that same form depending on which button is pressed.

Is that possible to pass text instead of parameters to the second form?
Thanks

 

[Minty]

OpenArgs is a string, so you can pass pretty much whatever you like with it.

If you set the open args to

1|Fred|23/04/2018|234

You can use the Split function to extract the four options separated by | from the string

 

[Danick]

OpenArgs is a string, so you can pass pretty much whatever you like with it.

If you set the open args to

1|Fred|23/04/2018|234

You can use the Split function to extract the four options separated by | from the string

Thanks but how do I get the different fields in the second form to insert those words in the appropriate fields?

Here is what I have:
On the first form, command button to open second form with the contactID

DoCmd.OpenForm "frmNewCall", , , , acFormAdd, , Me.ContactID

On load of 2nd form

Me.ContactID = Me.OpenArgs
Me.Subject.Value = Me.Subject.Value & "Call"

How can I change that so that I can have for example 2 buttons on the first form that will populate the Subject value to either "Call" or "email" depending on which button I press.

 

[Minty]

Lets change your open args to

DoCmd.OpenForm "frmNewCall", , , , acFormAdd, , Me.ContactID & "|Call"

Then in on load

Me.[ContactID] = Split(Me.OpenArgs, "|")(0)
Me.[Subject] = Split(Me.OpenArgs, "|")(1)

 

[Danick]

Lets change your open args to

DoCmd.OpenForm "frmNewCall", , , , acFormAdd, , Me.ContactID & "|Call"

Then in on load

Me.[ContactID] = Split(Me.OpenArgs, "|")(0)
Me.[Subject] = Split(Me.OpenArgs, "|")(1)

WOW - that was easy. Thank you so much. This works exactly the way I want it to work.

 

[Danick]

Thanks Uncle Gizmo.
I can see how this would be the "correct" way to do this and looks a whole lot more professional. For me though, modifying two lines of code to my OpenArgs is a whole lot easier than all this Function and VBA. I'll keep this in mind though the next time I have to do something like this.

The only concern I'm having now is why shouldn't I use OpenArgs in this way? Is it just bad policy or can it crash the application, reduce performance, etc,...

 

[MarkK]

I don't know. I don't mind concatenating OpenArgs like Minty does there, and then splitting them out again in the newly opened form. Maybe a matter of taste. The bigger problem is with a form opened acDialog, which pauses your calling code.
Mark

 

[MajP]

That's not really how OpenArgs was intended to be used!

Really? Who says? What was it intended for, if not to pass information to be used in code? It is a pretty common technique used often.

Now as pointed out it is only needed if the form is open dialog. I can not think of a reason to use it otherwise, but maybe there is.

 

[Danick]

I don't know. I don't mind concatenating OpenArgs like Minty does there, and then splitting them out again in the newly opened form. Maybe a matter of taste. The bigger problem is with a form opened acDialog, which pauses your calling code.
Mark

So I'm not really sure what you mean with this.

After one of the buttons is pressed in the first form, the first form is still left open in the background. So I suppose the user can leave the second form opened, go back to the first form, and then select a different button. I tried this and all that happens is the 2nd form gets the focus again, but doesn't update the fields to the new button selected. I can see that could be an issue. I don't really want to make the 2nd form a popup. It's fine for me, but I can see how some may find it a problem (if that's what you mean by having a problem from opened acDialog).

 

[MajP]

As Uncle Gizmo said, if you are not opening the form in dialog simply manipulate the properties of the open form, because you can. No need for openargs.

If the form is open in dialog, you cannot manipulate it because code execution from the calling form stops until the dialog form in closed. That is the only reason to use open args (unless someone provides a reason). If you need to pass multiple values then use a delimeter so you can split it out. There is no reason to use openargs on a non dialog form. As Gizmo points out it is far easier and efficient to just manipulate the properties.

 

[MajP]

If a form is open in Dialog I will argue that openargs is the best method to manipulate form properties. Your other option is to set a public variable ahead oftime, but this is not very encapsulated leading to other problems. If doing this is a more modern environment like vb.net you can instantiate the form, set the properties, and then open it, but Access is pretty primitive.

 

[JHB]

I have a command button on a form that open a second form and use OpenArgs to pass the ID that was in the first form.
..

I think you should use the event Activate instead, example attached.