Passing Values between forms

[RobVoip]

Hi Guys,

Having trouble passing a value from one form to another. The first form has 2 check boxes and an open commnad for a order form. The user clicks if the order is paid by check or Credit Card, then they open the order form and fill it out. In my orders table i have two fields created for CC and check. Basically depending on what the user clicked on the first form, when they save the record in the second form it will store all the values and the value if the user checked check or credit card.

Ive been playing around with the openargs command but i cannot seem to get this to work.

Any help would be appreciated.

[TheCPUWizard]

Extract the information into a class (forms should NOT hold state. Pass the instance of the class from one form to the other...

[Thread1]

OR... access Form1 directly from Form2:

if Form1.optCheck.Value then
msgbox "Check"
else
msgbox "Card"
end if

OR... pass the value into the Tag property of Form2...

OR... create a public property on either Form1 or Form2...

ETC...

[TheCPUWizard]

OR... access Form1 directly from Form2:

if Form1.optCheck.Value then
msgbox "Check"
else
msgbox "Card"
end if

OR... pass the value into the Tag property of Form2...

OR... create a public property on either Form1 or Form2...

ETC...

While any of these approaches WILL work, I would not recommend ANY of them (although they are common). The reasons are many, but the following are the highlights:

1) Having state (and/or logic) in Forms dramatically reduces the testablity of the code.

2) Tight coupling between the forms reduces re-use and create additional dependancies.

3) You can quickly end up with circular references with can kill scalability.

Thee are a bunch more, but these sould be enough to disuade any developer who is doing anything other than "playing with throw away code"

4) Throw-Away code has a very bad habit of lasting a long long long time.

[manu.patel]

Impressive...

While any of these approaches WILL work, I would not recommend ANY of them (although they are common). The reasons are many, but the following are the highlights:

1) Having state (and/or logic) in Forms dramatically reduces the testablity of the code.

2) Tight coupling between the forms reduces re-use and create additional dependancies.

3) You can quickly end up with circular references with can kill scalability.

Thee are a bunch more, but these sould be enough to disuade any developer who is doing anything other than "playing with throw away code"

4) Throw-Away code has a very bad habit of lasting a long long long time.

[Thread1]

While any of these approaches WILL work, I would not recommend ANY of them (although they are common). The reasons are many, but the following are the highlights:

1) Having state (and/or logic) in Forms dramatically reduces the testablity of the code.

2) Tight coupling between the forms reduces re-use and create additional dependancies.

3) You can quickly end up with circular references with can kill scalability.

Thee are a bunch more, but these sould be enough to disuade any developer who is doing anything other than "playing with throw away code"

4) Throw-Away code has a very bad habit of lasting a long long long time.

that is actually a good and general approach in software design. hope it will convince the OP to change his approach when all he wanted is passing values between forms . quite overkill but nice suggestions though

[WoF]

4) Throw-Away code has a very bad habit of lasting a long long long time.

The reason being, it works so well, is easy to understand and consists only of three lines of code.

I fully agree with the CPUWizard, about bad programming habits, but I dont consider it too bad, to access elements or variables of a form directly, as long as it is within a "closed" project of smaller size, where reuse of code is not a subject.
I would possibly even make these values properties of the Form and writing Property Get Procedures to access them.

[RobVoip]

Hi Guys,

Thanks for all your help. I will try your suggestions tonight.

[dglienna]

Then, there's always Global Variables