Form Reference Question (Getting Back Your Visual Basic 6.0 Goodies)

[gerryLowry::Ability Business Computer Services {KC]

"Getting Back Your Visual Basic 6.0 Goodies" by Billy Hollis, 2003-5-14,
states:

"Getting a Forms Collection
Visual Basic 6.0 developers are often fond of looping through the currently
loaded forms in an application to find out something, such as if a
particular form it loaded, or how many of a particular type of form are
loaded. Windows Forms does not include a Forms collection, however, so
gaining such functionality in Visual Basic .NET means some additional work."

Hollis gives an example were we have "Form1" and "Form2".

Form1 has TWO buttons ... the first button creates a number of instances
of Form2;
the second button uses a collection to make each instance of Form2
invisible.

PROBLEM

The above is like a FORWARD reference ... from the main form, to some other
form.

I am struggling with reversing the syntax ...

from other forms and other modules I would like to control Form1 ....
for example, when the end user clicks my control [some button] on Form2
which starts a routine myModuleCode, it would be nice if, in myModuleCode,
I could do something like:

....
"Form1".Visible = False ' Hide Form1 until processing is complete
.... ' start of processing
....
....
.... ' end of processing
"Form1".Visible = True ' Unhide Form1 because processing is
complete
....

My feeble attempts to adapt Hollis' example has only succeeded in causing a
variety of crashes. Using "Me", "Me.Name", et cetera, did not help me
discover the correct syntax.

Needless to say, the online help was useless (or perhaps it is I who is
useless at locating information just beyond my fingertips).

Rather than continuing to bang my brain against the syntax wall, I hope some
reader of this newsgroup will be kind enough to share her/his expertise in
this matter.

Thank you .... regards, gerry

 

[Chris]

"Getting Back Your Visual Basic 6.0 Goodies" by Billy Hollis, 2003-5-14,
states:

"Getting a Forms Collection
Visual Basic 6.0 developers are often fond of looping through the currently
loaded forms in an application to find out something, such as if a
particular form it loaded, or how many of a particular type of form are
loaded. Windows Forms does not include a Forms collection, however, so
gaining such functionality in Visual Basic .NET means some additional work."

Hollis gives an example were we have "Form1" and "Form2".

Form1 has TWO buttons ... the first button creates a number of instances
of Form2;
the second button uses a collection to make each instance of Form2
invisible.

PROBLEM

The above is like a FORWARD reference ... from the main form, to some other
form.

I am struggling with reversing the syntax ...

from other forms and other modules I would like to control Form1 ....
for example, when the end user clicks my control [some button] on Form2
which starts a routine myModuleCode, it would be nice if, in myModuleCode,
I could do something like:

....
"Form1".Visible = False ' Hide Form1 until processing is complete
.... ' start of processing
....
....
.... ' end of processing
"Form1".Visible = True ' Unhide Form1 because processing is
complete
....

My feeble attempts to adapt Hollis' example has only succeeded in causing a
variety of crashes. Using "Me", "Me.Name", et cetera, did not help me
discover the correct syntax.

Needless to say, the online help was useless (or perhaps it is I who is
useless at locating information just beyond my fingertips).

Rather than continuing to bang my brain against the syntax wall, I hope some
reader of this newsgroup will be kind enough to share her/his expertise in
this matter.

Thank you .... regards, gerry

As long as myModuleCode has a reference to "Form1" then you can do this.
You'll probably have to send in a reference to form1 to form2.
Something like:

public class form2
dim RefToForm1 as Form1
sub new(F1 as Form1)
mybase.new()
RefToForm1 = F1
end sub
sub myModuleCode()
RefToForm1.Visible = False
.....
RefToForm1.Visible = False
end sub
End class

note that this way of doing it causes you to create Form2 this way:

From inside Form1 somewhere...
dim F2 as new Form2(Me) 'This passes in the reference of form1 to form2

Hope it helps
Chris

 

[Gerry~Lowry]

| As long as myModuleCode has a reference to "Form1" then you can do this.
| You'll probably have to send in a reference to form1 to form2.
| Something like:
|
| public class form2
| dim RefToForm1 as Form1
| sub new(F1 as Form1)
| mybase.new()
| RefToForm1 = F1
| end sub
| sub myModuleCode()
| RefToForm1.Visible = False
| .....
| RefToForm1.Visible = False
| end sub
| End class
|
| note that this way of doing it causes you to create Form2 this way:
|
| From inside Form1 somewhere...
| dim F2 as new Form2(Me) 'This passes in the reference of form1 to form2
|
| Hope it helps
| Chris

Hi, Chris ... it may help ... although I sense potential problems in more complex programs ...

For example, Form1 opens Form2, Form2 calls the sub "chris" in Module1, "chris" hides Form1,
then, later, Form1 opens Form3, Form3 calls the sub "chris" in Module1, "chris" hides Form1.

This all appears to force far to much form to form to module or class communication.

Since ALL of these code units are compiled together, it would be so much
easier if one could say from ANYWHERE, in a simple syntax, something like

"Form1".Visible = <truth value>

It would have been so much easier if VB.NET had included the VB6 Forms collection.

g.

 

[Gerry~Lowry]

(Here's a somewhat kludgey* solution ... f.y.i.:

In Module1

Public myStartUpForm As Form

Public Sub setReferenceToForm1(ByRef myStartUpFormIs As Form)
myStartUpForm = myStartUpFormIs
End Sub

Public Sub showHideMyStartUpForm()
myStartUpForm.Visible = Not myStartUpForm.Visible
End Sub

In Form1 initialization

setReferenceToForm1(Me)

The global, myStartUpForm, should allow reference back to Form1 from anywhere.

g.)

* kludgey, and potentially buggy ... for example, if a general form referenced with
this method was closed, I am not sure what might result if the global was later
used ... something likely not pretty

| | As long as myModuleCode has a reference to "Form1" then you can do this.
| | You'll probably have to send in a reference to form1 to form2.
| | Something like:
| |
| | public class form2
| | dim RefToForm1 as Form1
| | sub new(F1 as Form1)
| | mybase.new()
| | RefToForm1 = F1
| | end sub
| | sub myModuleCode()
| | RefToForm1.Visible = False
| | .....
| | RefToForm1.Visible = False
| | end sub
| | End class
| |
| | note that this way of doing it causes you to create Form2 this way:
| |
| | From inside Form1 somewhere...
| | dim F2 as new Form2(Me) 'This passes in the reference of form1 to form2
| |
| | Hope it helps
| | Chris
|
| Hi, Chris ... it may help ... although I sense potential problems in more complex programs ...
|
| For example, Form1 opens Form2, Form2 calls the sub "chris" in Module1, "chris" hides Form1,
| then, later, Form1 opens Form3, Form3 calls the sub "chris" in Module1, "chris" hides Form1.
|
| This all appears to force far to much form to form to module or class communication.
|
| Since ALL of these code units are compiled together, it would be so much
| easier if one could say from ANYWHERE, in a simple syntax, something like
|
| "Form1".Visible = <truth value>
|
| It would have been so much easier if VB.NET had included the VB6 Forms collection.
|
| g.

 

[Chris]

| As long as myModuleCode has a reference to "Form1" then you can do this.
| You'll probably have to send in a reference to form1 to form2.
| Something like:
|
| public class form2
| dim RefToForm1 as Form1
| sub new(F1 as Form1)
| mybase.new()
| RefToForm1 = F1
| end sub
| sub myModuleCode()
| RefToForm1.Visible = False
| .....
| RefToForm1.Visible = False
| end sub
| End class
|
| note that this way of doing it causes you to create Form2 this way:
|
| From inside Form1 somewhere...
| dim F2 as new Form2(Me) 'This passes in the reference of form1 to form2
|
| Hope it helps
| Chris

Hi, Chris ... it may help ... although I sense potential problems in more complex programs ...

For example, Form1 opens Form2, Form2 calls the sub "chris" in Module1, "chris" hides Form1,
then, later, Form1 opens Form3, Form3 calls the sub "chris" in Module1, "chris" hides Form1.

This all appears to force far to much form to form to module or class communication.

Since ALL of these code units are compiled together, it would be so much
easier if one could say from ANYWHERE, in a simple syntax, something like

"Form1".Visible = <truth value>

It would have been so much easier if VB.NET had included the VB6 Forms collection.

g.

You could make Form1 a module level variable and give everyone access,
but this does not really follow the OO method of development. You could
make your own forms collection if you wanted, again same issue.

"This all appears to force far to much form to form to module or class
communication."

How is this a problem. I also don't see how it's form to form to module
communication... Form2 hides Form1, calls the module, shows Form1.
You could handle this as an event I guess. Make an event in Form2
called "StartProcess" and one called "EndProcess" Then have Form1
handle the Form2 events.

in Form2:

RaiseEvent(StartProcess)
callProcessFunction
RaiseEvent(StopProcess)

in Form1
'This could be done dynamically use addhandler/removehander instead of
using "handles" keyword
private sub StartProcess_Handler() handles form2.StartProcess
me.visible = false
end sub

Chris

 

[Gerry~Lowry]

| You could make Form1 a module level variable and give everyone access,
| but this does not really follow the OO method of development. You could
| make your own forms collection if you wanted, again same issue.

I think that is basically what I have done
in the kludge that I just posted. I agree with
you ... it's ugly and very un-OO.

| "This all appears to force far to much form to form to module or class
| communication."
|
| How is this a problem. I also don't see how it's form to form to module
| communication... Form2 hides Form1, calls the module, shows Form1.

Chris, perhaps I was a bit unclear here. In some business
applications, it would be convenient to be able to safely
call any module and/or control any form from any point in code.

It seems a bit like a bucket brigade, with each form passing
references down the call hierarchy, just so that any form
that might need it would have access to it.

| You could handle this as an event I guess. Make an event in Form2
| called "StartProcess" and one called "EndProcess" Then have Form1
| handle the Form2 events.
|
| in Form2:
|
| RaiseEvent(StartProcess)
| callProcessFunction
| RaiseEvent(StopProcess)
|
| in Form1
| 'This could be done dynamically use addhandler/removehander instead of
| using "handles" keyword
| private sub StartProcess_Handler() handles form2.StartProcess
| me.visible = false
| end sub
|
| Chris

Chris, your event idea has a good degree of elegance.
It may be the best possible and the most consistent
solution.

Thank you ............ gerry

 

[Armin Zingler]

Hi, Chris ... it may help ... although I sense potential problems in
more complex programs ...

For example, Form1 opens Form2, Form2 calls the sub "chris" in
Module1, "chris" hides Form1, then, later, Form1 opens Form3,
Form3 calls the sub "chris" in Module1, "chris" hides Form1.

This all appears to force far to much form to form to module or
class communication.

Maybe you should rethink the design. Just curious: Why do you have to pass
Forms around so often? Even without a global "Form1" variable I don't have
to do it often, also not in more complex apps.

A basic rule is: If you want to access an object, you need a reference. If
you don't have one, you have to pass it. I've never needed an exception for
Forms.

In addition, you can always write "public shared f1 as form1" in a class to
make it available everywhere. But be careful: The object can be modified
from the whole project and finding errors can get complicated.

Since ALL of these code units are compiled together, it would be so
much
easier if one could say from ANYWHERE, in a simple syntax, something
like

"Form1".Visible = <truth value>

It would have been so much easier if VB.NET had included the VB6
Forms collection.

Armin

 

[Gerry~Lowry]

Armin ... it's not my design ... the particular designer has a familiar style
derived from the xBase DOS world ... the designer's theory is that the staff
are familiar with applications acting a certain way ... by acting upon
forms somewhat dynamically, the designer is simulating the legacy DOS system's
application behaviour. In Access and in VB6, the designer's goals
are somewhat more easily met.

| > Hi, Chris ... it may help ... although I sense potential problems in
| > more complex programs ...
| >
| > For example, Form1 opens Form2, Form2 calls the sub "chris" in
| > Module1, "chris" hides Form1, then, later, Form1 opens Form3,
| > Form3 calls the sub "chris" in Module1, "chris" hides Form1.
| >
| > This all appears to force far to much form to form to module or
| > class communication.
|
|
| Maybe you should rethink the design. Just curious: Why do you have to pass
| Forms around so often? Even without a global "Form1" variable I don't have
| to do it often, also not in more complex apps.
|
| A basic rule is: If you want to access an object, you need a reference. If
| you don't have one, you have to pass it. I've never needed an exception for
| Forms.
|
| In addition, you can always write "public shared f1 as form1" in a class to
| make it available everywhere. But be careful: The object can be modified
| from the whole project and finding errors can get complicated.

Agreed. I would not want to risk this unless I were desperate.

thank you / gerry