opening a Child form with parameters 1

[ciaranr]

Am I thick? How do i open a child form with a paremeter?
eg. A child form finds a client and i wish to open a second child form based on the client ID.
I have found a work around but it appears to be clumbsy.

any help?

ciaran
ciaranr@albany.jrc.net.au

 

[jmarler]

ciaran,
What you need is a constructor which, sad to say, VB6 does not offer (VB.Net will have this feature). Until then, the only real option you have is to use a public fucntion to pass your data to the form before you show it. For example . . .

Dim objForm as Form1

set objForm = New Form1

call objForm.SetParameters(1,2,"some data")
objForm.Show

Where SetParameters was a public function/sub on your form. - Jeff Marler B-)

 

[rvBasic]

Basically you want to share a variable between two forms at startup time of the second form. Properties are the ideal public functions to do so as illustrated in thread222-37333 or faq222-400.

If Form1 sets the property (client ID), then Form2 can get it at its initialization event. This technique can be used to implement (limited) constructor facilities. _________________________________
In theory, there is no difference between theory and practice. In practice, there is. [attributed to Yogi Berra]

 

[WildBillH]

Here is one way to simulate passing a parameter into a form (let's refer to the form as "MyForm&quot:

1. On MyForm, create a label called ParamLabel, then set the MyLabel.Visible property to false.

2. Now, let's say you want to pass the value "ABCD" to MyForm as a parameter. Put the following line in the appropriate place in the calling module (or form, or whatever):

MyForm.ParamLabel.Caption = "ABCD"

Here is what happens: You referred to an object (ParamLabel) on a form (MyForm). MyForm will be loaded automatically (if it hasn't been already), and "ABCD" is placed into the label's Caption property. In your MyForm code, you can now test the value of ParamLabel.Caption and use it as if it were a parameter.

WB

 

[ciaranr]

Thanks all
My clumbsy method is the same as WildbillH. It would seem that it is not as clumbsy as I first thought. One question though, what is the difference in CPU/system resource usage between the above two methods?


ciaran
ciaranr@albany.jrc.net.au

 

[BasSchouten]

I dont know about the CPU-resources both options use, but i certainly know the first option (using a propery, and acting on setting or changing the property in the last child form) is much more flexible and more "clean programming". It allows you to not only give a text as a parameter but anything you wish (object, enum, ...), depending on the definition of your property

It uses OO-technology as far as VB knows it.
Bas Schouten
System Development & Webdesign
CBIS BV Holland

 

[rvBasic]

As you could easily guess, I agree with BasSchouten. I didn't measure cpu utilization, because I tend to favor future maintenance over performance concerns (within reasonable bounds however).

With this regard, it is my understanding that VB.NET will NOT even allow for the "clumsy" method where a control (ParamLabel) is directly referenced on the form. (cfr. 10 Ways to Prepare for VN.NET in VB Programmer's Journal, December 2000, p 63).

On the other hand, the Property method can be easily migrated. _________________________________
In theory, there is no difference between theory and practice. In practice, there is. [attributed to Yogi Berra]

 

[WildBillH]

I have to agree with the above criticism of my "clumsy" solution. However, it was the best I could come up with in attempting a direct response to the question -- how to pass a parameter during form invocation.

In truth, there is not a direct way to do this in VB6. While my solution makes an attempt to simulate parameter passing, I have to agree that the other suggestions are surely better from a technical standpoint. The only drawback that I can see is the reliance upon public (globally-scoped) variables, but VB6 does not seem to offer a reasonable alternative.

By the way -- thanks to rvBasic for the VB.Net comment. It is good to have a "heads up" warning about what lies in the future, especially when a suggested programming technique may not work as expected with the next release of VB.

WB

 

[rvBasic]

The only drawback that I can see is the reliance upon public (globally-scoped) variables, but VB6 does not seem to offer a reasonable alternative.

Properties are indeed Public. But they are in reality Functions which can be used to check the validity of the input parameters, just as any function can do. As such they offer an integrity checking that you do not have with Public Variables.

An often overlooked possibility is that the Function can be made Write Once so that the Property cannot be changed by subsequent assignments.
Following code snippet illustrates the principle:

Private m_strMyProperty As String

Public Property Let MyProperty ( strInput as String)

Static bWriteOnce as Boolean

Select Case WriteOnce
Case False
'Assign value to internal property
m_strMyProperty = strInput
bWriteOnce = True
Case True
'Do Nothing - Value already set
End Select
End Property


_________________________________
In theory, there is no difference between theory and practice. In practice, there is. [attributed to Yogi Berra]