Solved Double Open Args or Single or Nothing (1 Viewer)

[AlexN]

Hi everyone,

I have two forms, FormA and FormB.
On FormA I have two controls "SupplierID" and "CustomerID" that are comboboxes from which I select values respectively.
On FormB there are the same two controls, only this time they are textboxes.
With a command button on FormA I close FormA and open FormB.
What I want to accomplish is:

• If any SupplierID selected in FormA to pass to the corresponding textbox in FormB.
• If any CustomerID selected in FormA to pass to the corresponding textbox in FormB.
• If Both selected, both to pass to the corresponding textboxes in FormB
• If none selected nothing to pass to the corresponding textboxes in FormB.

Both forms are bound to tables respectively and the command button in FormA opens FormB on NewRecord
Any ideas?


Thanks

 

[Minty]

I would use the NZ() function to pass the values or an obvious "Non value" e.g. 0

Dim sArgs as String

sArgs = NZ(Me.SupplierID,0) & "|" & NZ(Me.CustomerID,0)

This will pass

"0|0" for nothing
"123|321" for both

if those were the values or a combination of the two.
You can then use those values in the form load event to populate the corresponding controls on form B.
If you don't have it already you can split out the text using this simple function;

Public Function ParseText(textin As String, X) As Variant
    On Error Resume Next
    Dim Var As Variant
    Var = Split(textin, "|", -1)
    ParseText = Var(X)


End Function

So to get the first value in the open args use

Me.MySupplierControl = ParseText(Me.OpenArgs,0)

The split function array numbering starts at 0

 

[arnelgp]

on Load event of FormB:

Private Sub Form_Load()
Me!supplierID = Forms!FormA!supplierID
Me!CustomerID = Forms!FormA!CustomerID
End Sub

 

[AlexN]

Thank you!!!
Looks promising. Haven't try it yet but looking at it a question comes up:
What happens in case of 0|321 (that's the case when SupplierID is Null but CustomerID exists)
That is, how to determine to which control of FormB to put the value

Thanks

 

[AlexN]

on Load event of FormB:

Private Sub Form_Load()
Me!supplierID = Forms!FormA!supplierID
Me!CustomerID = Forms!FormA!CustomerID
End Sub

That would premise that FormA is still open. And what happens when you open FormB by itself (not form the command button on FormA)?

 

[arnelgp]

if FormA is not open, test it (still on FormB Load Event) if it is not:

Private Sub Form_Load()
If SysCmd(acSysCmdGetObjectState, acForm, "FormA") <> 0 Then
    If Forms!FormA.CurrentView <> 0 Then 'FormA is open and not in design view
        Me!SupplierID = Forms!FormA!SupplierID
        Me!CustomerID = Forms!FormA!CustomerID
    End If
End If
End Sub

 

[Uncle Gizmo]

I don't like sending multiple values through "open args" it just don't seem right. Mind you, there are situations where it's your only option.

With ArnelGP's solution, if form A is closed, you loose access to the values.

I prefer to send values through to custom form properties:-

More info and explanatory videos Here:-

Open one Form from Another and transfer Data - Nifty Access

Passing Form Values A common requirement is to pass values from one form to another. In these videos I demonstrate some problems you might face, and demonstrate a good and robust way of doing it. Open One Form From Another Open One Form From Another Video 1 (3:15) I have used the technique shown...

www.niftyaccess.com

 

[Gasman]

I see nothing wrong with sending multiple values via OpenArgs.
I am not a fan of harcoding object names though, I used to prefer setting a tempvar or two

 

[AlexN]

Thank you all for your answers.
I tried Minty's solution and works perfectly!

Thanks again! You guys are wonderful.

 

[MajP]

With a command button on FormA I close FormA and open FormB.

The only time you ever need to use open args is if you open FormB from form A using ACDIALOG to stop execution in form A. If not simply set the values form B before closing form B

docmd.openform "FormB"
With forms("FormB")
  .SupplierID = me.supplierID
  .CustomerID = me.CustomerID
end with
docmd.close ACFORM, Me.name
  .

1) No need to send or split open args (overly complicated)
2) no need to hardwire or tightly couple FormB to form A
3) no need to check if open args are passed or not
4) no need to check if other forms are open

 

[AlexN]

The only time you ever need to use open args is if you open FormB from form A using ACDIALOG to stop execution in form A. If not simply set the values form B before closing form B

docmd.openform "FormB"
With forms("FormB")
  .SupplierID = me.supplierID
  .CustomerID = me.CustomerID
end with
docmd.close ACFORM, Me.name
  .

1) No need to send or split open args (overly complicated)
2) no need to hardwire or tightly couple FormB to form A
3) no need to check if open args are passed or not
4) no need to check if other forms are open

Thanks for your reply too. I know what you mean and it's lovely. arnelgp's solution is functional too, being on the same path but, I find Minty's more 'educational' and keep it for future reference .

 

[MajP]

I find Minty's more 'educational' and keep it for future reference .

There are times to pass OpenArgs and there are times to pass multiple values in OpenArgs. It is good to know this. As long as you understand this is pretty rare case. If not you are picking an overly complicated means with several vectors for failure.
ArnelGP solution works, but this is a tightly coupled solution. A popup form should never push or pull data. It should be pushed data from the form that calls it then it can work from any form or no form calling it.

 

[Uncle Gizmo]

I find Minty's more 'educational' and keep it for future reference

In my experience, there are generally three ways of doing the same thing!

The merits of each way are often debated, but basically, it comes down to what you are comfortable with, do it the way that suits you and you can't go wrong!

 

[Minty]

It is often the case with Access there are at least 3 ways to provide a solution.
As others have suggested OpenArgs is a simple route, but maybe not the most programmatically sound.

 

[MajP]

it comes down to what you are comfortable with, do it the way that suits you and you can't go wrong!

Sure if all you have is a hammer everything looks like a nail.

There are often many ways to code a solution, and sometimes they are debatable. One may be more reusable, the other less error prone, one easier to understand, the other easier to implement. When I see a different way of doing things I weigh it out and understand why the user implemented it that way and learn from there and add it to the toolbox if needed. I do not still use my hammer in all situations, but use the new tool in the right situation
But if I see a solution that across the board is simpler, less chance of error, more flexible, less tightly coupled than all others then that is the solution I will use in the future even if the hammer still can get it done.

 

[Uncle Gizmo]

When I see a different way of doing things I weigh it out and understand why the user implemented it that way and learn from there and add it to the toolbox

Same here! When I started out, I used to write code for each controls event. But I saw other people had written code which looped through the control collection, achieving the same result.

It took much study and head scratching to work out what was going on.