How does one simply open one form from another ?

[Barret Bonden]

As an old programmer just now looking at VB.net I have a question:

How does one simply open one form from another ? I don't mean how does one
create a new instance of that form , but rather how to refer to THAT form ?
And having done this, how does one get data to and from that form ?

I have read the MS tutorial on this but it is senselessly complex; there
must be a simple, straightforward method, or I can only assume that MS has
destroyed a useful tool (VB) in the absurd following of the OO obsession
.....

 

[Cor Ligthert]

Barret,

I don't know what that usefull tool is, however you now create different
kind of forms and directly from your main form.

There are MDI child forms, dialogforms and normal form.
Basicly it is all the same however the way of showing is different

for a normal form it is
\\\
dim frm as new form2
frm.show
///

That is all.

I hope this helps?

Cor

"Barret Bonden"

 

[Herfried K. Wagner [MVP]]

As an old programmer just now looking at VB.net I have a
question:

How does one simply open one form from another ? I don't
mean how does one create a new instance of that form , but
rather how to refer to THAT form ? And having done this,
how does one get data to and from that form ?

You'll have to store references to your forms' default instances somewhere,
or implement the Singleton design pattern for your form classes for easily
accessing the default instances.

I have read the MS tutorial on this but it is senselessly
complex; there must be a simple, straightforward method,
or I can only assume that MS has destroyed a useful tool
(VB) in the absurd following of the OO obsession

ACK. Hopefully, default instances for forms will be back in VB 2005.

 

[Larry Serflaten]

ACK. Hopefully, default instances for forms will be back in VB 2005.

Why would you want auto-instantiating forms back? They were the
source of many problems including 'My app won't shut down' type
of problems. The main point is that no other objects are auto-instantiating
so why make forms act that way?

IMHO it would be better to tell the developer how to add that functionality,
rather than have it included in the language. If they include it, we all have to
live with it, but if there is a simple workaround to bring it back, then those
who want it, can have it, while those who don't won't have to consider it a
possible source for errors.

Doesn't this code provide that functionality:

Module Module1
Public MyForm1 As New Form1
Public MyForm2 As New Form2
End Module


With the above, both MyForm1 and MyForm2 are auto-instantiating.

IMHO, That would be the better solution. What do you think?

LFS

 

[Herfried K. Wagner [MVP]]

Why would you want auto-instantiating forms back?

Take a look how many beginners cannot be productive because they need to
understand the current form model. The current model is nice, but IMO a
simplification would be a step forward to a more RAD experience, especially
for beginners.

Notice that I do not talk about the current implementation (beta versions of
Whidbey). This implementation definitely sucks. But the problems can be
fixed.

 

[Cor Ligthert]

Herfried,

In my idea wrong

Take a look how many beginners cannot be productive because they need to
understand the current form model. The current model is nice, but IMO a
simplification would be a step forward to a more RAD experience,
especially for beginners.

That sentence should be in my opinion.

Take a look how many persons who where used to VB6 and than go
on................

That is a very bad reason.

There will be more and more beginners who never saw VB6 and than you keep
them on the bad methods.

I have the same idea in this as Larry (not his solution. It is well as it is
now in my idea).

Just my thought as you know

Cor

 

[Herfried K. Wagner [MVP]]

Take a look how many beginners cannot be productive
because they need to understand the current form model.
[...]

That sentence should be in my opinion.

Take a look how many persons who where used to VB6 and than go
on................

That is a very bad reason.

That's another story.

On the one hand, there are those VB6 developers who make their first steps
with VB.NET and miss default instances and the simplicity known from VB6.

On the other hand, there are complete newbies who are not fully aware of OOP
programming and thus have problems to deal with different forms, accessing
controls on other forms' instances, etc.

A solution to the issue needs to satisfy both of the groups described above.

There will be more and more beginners who never saw VB6
and than you keep them on the bad methods.

Default instances in general are /not/ a bad method. They are a valuable
shortcut.

 

[Larry Serflaten]

Take a look how many beginners cannot be productive because they need to
understand the current form model.

Cor added more on the point I was making: The people who have trouble
are those who are expecting VB6 fucntionality. Programming 'beginners'
over the next decade (or more) will not have that predisposition, and to them,
forms should act just like every other class in the framework.

Notice that I do not talk about the current implementation (beta versions of
Whidbey). This implementation definitely sucks. But the problems can be
fixed.

I don't have the 2005 beta installed, but I hear talk that the forms will be
available through the My.Forms shortcut. In that instance I could see where
auto-instantiation might be the better way to go, but to add that functionality
globally is (IMHO) a large mistake.

LFS

 

[Herfried K. Wagner [MVP]]

Cor added more on the point I was making: The people
who have trouble are those who are expecting VB6 fucntionality.

I agree, they expect VB6 functionality.

But many newbies (without exprience with VB6) are confused by the
complicated form model too. It's simply unpractical. It's too complicated
to manage references to forms when only one instance of a form is needed.

In VB6, a newbie simply typed 'Call Form1.Show' and the form was shown.
He/she typed 'Form1.BackColor = vbRed' and the form's backcolor turned into
red. It was much easier to access the single instance of a form. No need
for implementing a Singleton or creating a reference store somewhere.

Programming 'beginners' over the next decade (or more) will
not have that predisposition, and to them, forms should act
just like every other class in the framework.

OOP is hard to understand, especially for beginners. Beginners start with
procedures and do not care about objects. But beginners want to be
productive in order to experience playing around with the programming
language as an interesting and fascinating task. I remember the time when I
developed my first Visual Basic application. Creating it was sooo easy. I
didn't have to know much about "objects", "references", "instances", ...

If VB.NET should be a language designed for beginners too, then an easier
way to create an applications UI infrastructure is required. A large number
of beginners will lead to a large number of professional developers using a
certain programming language. Programming languages that introduce
complexity by adding heavy requirements like full knowledge of OOP when
writing their first program, won't have a future.

I don't have the 2005 beta installed, but I hear talk that the
forms will be available through the My.Forms shortcut.

That's right. Notice that the default instances will only be created "by
need", so if you don't use them, don't worry about them.

 

[Larry Serflaten]

Default instances in general are /not/ a bad method. They are a valuable
shortcut.

I'd suggest they are bad.

1. They are the source of problems when the app is shutting down
2. They are a source of problems when some use default styles while
others use explicit, in the same program.
3. They would be an unexplained exception to the patterns used by all
other classes in the language.

Adding a form to a project does not 'call it into existance by default'
any more than adding other classes. Having to explicitly declare the
forms is no different than explicitly declaring other classes. It is also
not far from having to explicitly declare variables, so the concept is
not going to be totally unfamiliar to the novice. With Option Explicit
on, variables have to be declared before use, and are constrained by
scoping issues. There is very little different when looking at objects.

The kicker is that, if you insert that functionality globally, then everyone
has to deal with it, where as if you simply provide a work around you
get two benefits:

1. The functionality is made available
2. The users are reminded that a 'workaround' is not normal use.
(IOW it may be better for them to deal with it in a more uniform way)

I realize this is a polarizing issue, some like it one way, and others like it
the other, but again, if it gets added, we all have to deal with it. Why
add a stumbling block to normal development???

LFS

 

[Larry Serflaten]

But many newbies (without exprience with VB6) are confused by the
complicated form model too. It's simply unpractical. It's too complicated
to manage references to forms when only one instance of a form is needed.

Compare that to using the random number feature, or a bitmap. You simply
can't call things into existance without first declaring them. It is that way for
variables (Explicit ON) and all other classes. And, with the declaration comes
scoping issues. My point is that they will be learning about that pattern anyway,
so that fact that it applies to every class will be a help. Making forms an
exception, is just that, yet another exception that has to be remembered.

In VB6, a newbie simply typed 'Call Form1.Show' and the form was shown.
He/she typed 'Form1.BackColor = vbRed' and the form's backcolor turned into
red. It was much easier to access the single instance of a form. No need
for implementing a Singleton or creating a reference store somewhere.

But using the store will remind them that they are taking a shorcut, which is
the 'reasoning' behind why it acts differently than every other class.

OOP is hard to understand, especially for beginners. Beginners start with
procedures and do not care about objects.

I have to disagree here because of the reasons stated. Any beginner who
wants to use functionality in the framework (StringBuilder for instance) has
to declare a variable of that type and use the New keyword. Its no different
than anything else they'll need, so why make forms act differently?

That's right. Notice that the default instances will only be created "by
need", so if you don't use them, don't worry about them.

If auto-instantiation is limited to syntax like: My.Forms.Form1.Show
I'll have no problem with it, but if they make this work: Form1.Show
Then it will be a source of problems (again!)

If they do make My... available then it may happen coders will do this:

My.Forms.Form1.Show
Form1.Textbox1.Text = "Enter name here"

How would you think that should respond?

And then after the form closes, and execution arrives at a line like the
above, how should it respond? If that later case throws an error
(because the form is no longer instantiated) then those logical errors
that keep programs alive will be easier to find. But such mixing up of
access seems to be ADDING confusion, not removing it.

It is really a simple concept, if they want a variable available to the entire
project, what do they need to do? And, if they want a form available to
the entire project, what do they need to do? You advocate forms act
differently than other declarations, I'd say they should act like everything
else....

LFS

 

[Cor Ligthert]

Herfried,

Your messages and also from Larry would lead for me for more wizards, not
for implementing things in the language itself, I assume that Larry has
almost the same ideas like me with this.

This will give the beginner the change to build a complete program and later
check the code and make more advantage things for that.

However not one as the dataform wizard, that is almost directly clossed for
changes because it uses an inbuild strongly typed dataset what is not
possible (or difficult) to change.

Cor

 

[Herfried K. Wagner [MVP]]

Your messages and also from Larry would lead for me for
more wizards, not for implementing things in the language
itself, I assume that Larry has almost the same ideas like
me with this.

I am not a great fan of wizards. I hate most wizards, and I consider most
wizards useless for beginners. Take the VB6 application wizard for example.
This wizard could be used to create an explorer style application without
typing a single line of code. Really? No. The wizard created a skeleton,
the necessary controls (something even a beginner is able to click together
in the forms designer) but it didn't add much valuable code. In order to
use the skeleton created by the wizard, the beginner had to remove the
controls he/she didn't need and he would never have added to the form if he
designed it himself/herself.

In my opinion, the main point is making writing code simpler. Creating
inter-form relations is a code-only job. Currently. Maybe there will be a
graphical designer that allows to specify inter-form relations in a
graphical and declarative way, which will generate the code automatically.
That's all in far future.

Another important point is transparency. I'll provide another sample to
illustrate what I am thinking. In VB6 the form designer generated code (in
fact it was a declarative description of the form layout, something similar
will be back with XAML) was completely invisible to the programmer. Sure,
the programmer could view it using the editor to view the form files. There
were very few issues and problems with this model. Beginners didn't have to
worry about form generation code, mainly because they didn't see it. In
VB.NET, every user, even a beginner, will be able to see 'Sub
InitializeComponent', things he/she should not even edit manually. I know
that some people consider that to be a step forward, but for me it's a step
into the wrong direction. Unnecessary things are not as transparent as in
VB6, code is more low-level than in VB6.

In the case of default instances, it is very similar. Even if a wizard is
able to make forms implement the Singleton design pattern, the user will be
able to browse this code and thus be faced with low-level stuff he/she does
not understand. The implementation code of a Singleton is an implementation
detail that /should not/ be seen by the programmer, it should be completely
transparent.

To make a conclusion: I like the idea of extending the programming language
with very high-level constructs which allow to write forms code and code for
inter-form communication quickly, without worrying about the implementation.
I am aware of the fact that such a feature needs to be designed carefully.

Don't forget that the most important thing is encapsulation, in other words,
an increase in transparency. That's what helps us to understand complex
scenarios. For a beginner, and for a professional too, inter-form
communication code is an implementation detail that isn't so important to
worry about.

This will give the beginner the change to build a complete
program and later check the code and make more advantage
things for that.

Why let the beginner auto-generate tons of crappy code? Instead, a
simplification of the code by introducing powerful code constructs would
allow even beginners to write perfect code in less time.

"Using forms' default instances should be considered "best practice"" --
there is no negative impact caused by the use of default instances if they
are implemented in a clean way.

 

[Cor Ligthert]

Herfried,

A long message, first of all, I do not like wizards at all and certainly not
how it is now implemented, however it can fullfils in my opinion the need in
this and your previous message when it is well done. (You cutted of in your
quoting from my previous message where I told about the in my eyes not good
implementation)

Second you are in my opinion argue for two different VB programs
VBNet and VB7 what than is the successor from VB6 or let that what is now a
good programmers tool VBNet devaluate to a real successor of VB6 and than
let all professionals go to C#.

We do not agree in what I write next, however I hope that you let me free
that in my eyes VB6 is a very crapy thing. Because that your statements are
not wrong, do I think that what you want better can be fullfiled with
Ms-Access in future.

However just my idea.

Cor

 

[Herfried K. Wagner [MVP]]

Cor,

Second you are in my opinion argue for two different VB
programs VBNet and VB7

It's not me who claims VB.NET to be the successor of VB6. It's Microsoft.

what than is the successor from VB6 or let that what is now a good
programmers tool VBNet devaluate to a real successor
of VB6 and than let all professionals go to C#.

VB6 has always been used in a professional environment too. Many
"beginners" and non-professionals who started with VB Classic, are now
professional VB6/VB.NET programmers.

We do not agree in what I write next, however I hope that
you let me free that in my eyes VB6 is a very crapy thing.

That's your opinion, and I respect this opinion. I think that VB6 is better
than people say. It's very high-level, it provides powerful language
elements that make life much easier if they are used the right way.

not wrong, do I think that what you want better can be fullfiled with
Ms-Access in future.

LOL!

 

[Herfried K. Wagner [MVP]]

Compare that to using the random number feature, or a
bitmap. You simply can't call things into existance without
first declaring them.

You can access shared members without instantiating an object through your
code. You can call a shared factory method that will create the instance
for you. The fact that you cannot see the declaration/instantiation is IMHO
not that important.

I doubt that anybody will have problems to understand default instances.

Making forms an exception, is just that, yet another exception
that has to be remembered.

Everybody is free to use default instances or not. There are so many
exceptions, and tools which are adapted to the most common context can be
used in a more productive way.

But using the store will remind them that they are taking a
shorcut, which is the 'reasoning' behind why it acts differently
than every other class.

Currently everybody builds his/her own references store. There is no
unified solution provided by the framework/programming language. I don't
know how the best "fix" to this will look like and if default instances are
the right way, but I honestly don't know a much better solution.

I have to disagree here because of the reasons stated. Any
beginner who wants to use functionality in the framework
(StringBuilder for instance)

I doubt that beginners will use 'StringBuilder' ;-))).

has to declare a variable of that type and use the New
keyword.

Most stringbuilders are referenced by local variables and are used in a
local context. That's easy to understand, and the lifetime of a local
object is easy to understand.

Its no different than anything else they'll need, so why make
forms act differently?

In order to make forms work together, references between the instances of
the forms need to be exchanged. That's harder than using a stringbuilder
and requires more knowledge about OOP.

If auto-instantiation is limited to syntax like: My.Forms.Form1.Show
I'll have no problem with it, but if they make this work: Form1.Show
Then it will be a source of problems (again!)

Full ACK!!! I like the first, but I don't like the latter, because it will
lead to problems.

the entire project, what do they need to do? You advocate
forms act differently than other declarations, I'd say they should
act like everything else....

I don't advocate forms to work differently from other objects, but I prefer
a unified way to store forms references and to access the forms' instances.
'My.Forms' is IMO a good idea. Referencing the default instance over the
form's class name is IMO a /bad/ idea.

 

[Larry Serflaten]

Beginners didn't have to
worry about form generation code, mainly because they didn't see it. In
VB.NET, every user, even a beginner, will be able to see 'Sub
InitializeComponent', things he/she should not even edit manually. I know
that some people consider that to be a step forward, but for me it's a step
into the wrong direction.

I agree that the low-level glue should be kept hidden, and I mentioned that
during the beta process (suggesting they hide it in a Region):

http://discuss.develop.com/archives/wa.exe?A2=ind0010A&L=DOTNET&P=R146&I=-3

But now I hear there are going to be 'partial' classes such that all that
machine generated code can be left out of the code module the developer
uses and stuffed into a 2nd 'partial' module. It seems that would be the
place for the things you mention....

LFS

 

[Herfried K. Wagner [MVP]]

Larry,

[Making auto-generated code transparent]

I agree that the low-level glue should be kept hidden, and I
mentioned that during the beta process (suggesting they hide
it in a Region):

http://discuss.develop.com/archives/wa.exe?A2=ind0010A&L=DOTNET&P=R146&I=-3


But now I hear there are going to be 'partial' classes such that
all that machine generated code can be left out of the code module
the developer uses and stuffed into a 2nd 'partial' module. It seems
that would be the place for the things you mention....

That is indeed a viable way. I hope that it won't cause too much confusion
though.