VB6 vs VB .NET

[R]

In the "good old days"... I used to put most of my code in different
modules, to keep it tidy, then it was no problem writing in a module like:

Form1.textbox1.text = "Some text"

or from a form

Form2.textbox1.text = me.textbox2.text

Now, in vb.net iI get an error saying "Reference to a non-shared member
requires an object reference". OK, so I read that I need to

Dim FormSomething aAS New Form1

then I can

FormSomething.TextBox1.Text = "Some text"

But, FormSomething is not the same form as Form1, I can't see the text.....

Is there a way around it or am I stuck?

Same thing about procedures on a form and I want to run them from a
different form or module, this I can, but if I use values from the form in
te proceure I get the wrong result.

If I on Form1 has code like this

sub get_Customer_Info ()
....
qeryString="SELECT * FROM Cust WHERE KID='" Me.txtKID.text "'"
...
end sub

And then I try to run this from Form2 with this code:
Dim newForm As New Form1
Form1.get_Cstomer_Info

The get_Cstomer_Info procdure wil run, but the value of txtKID.text will be
the text you set at design time.

Please help me here, I'm a frustrated VS.NET newbie
Ronny

[Rick Mogstad]

"R" <[e-mail]> wrote in message news:Tl****************@news4.e.nsc.no...

FormSomething.TextBox1.Text = "Some text"

But, FormSomething is not the same form as Form1, I can't see the text.....

Is there a way around it or am I stuck?

I assume that Form1 is your startup form? Perhaps use a sub Main as your startup. The problem is
that The form you see is a different instance than FormSomething. They are both of type Form1,
but different instances. If you call the FormSomething.Show then you will see that FormSomething
will pop up, and the text will be correct.

[Armin Zingler]

"R" <[e-mail]> schrieb

Is there a way around it or am I stuck?

If you want to access an object, you need a reference. If you don't have a
reference you have to make it available. This was the same in VB6.

The .NET Framework contains several hundreds (or thousands) of classes.
There is no reason why classes derived from System.Windows.Forms.Form have a
global, automatically created, automatic instancing and invisible variable
with the same name of the Form, whereas the other hundreds don't have such a
variable.

If you want to have the same behavior as in VB6, you can write in a Module:

Private m_Form1 As Form1

Public Property Form1() As Form1
Get
If m_Form1 Is Nothing Then
m_Form1 = New Form1
End If
Return m_Form1
End Get
Set(ByVal Value As Form1)
m_Form1 = Value
End Set
End Property
Instead, I still would pass the reference to the object that needs it.

--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Jan Tielens]

Check out following article:
http://tinyurl.com/el1

Working with Multiple Forms in Visual Basic .NET: Upgrading to .NET

Describes how working with multiple forms has changed from previous editions
of Microsoft Visual Basic and illustrates several key techniques, including
displaying a second form, changing the appearance of another form, and using
a form as a dialog.

--
Greetz

Jan Tielens
________________________________
Read my weblog: http://weblogs.asp.net/jan
"R" <[e-mail]> wrote in message news:Tl****************@news4.e.nsc.no...

In the "good old days"... I used to put most of my code in different
modules, to keep it tidy, then it was no problem writing in a module like:

Form1.textbox1.text = "Some text"

or from a form

Form2.textbox1.text = me.textbox2.text

Now, in vb.net iI get an error saying "Reference to a non-shared member
requires an object reference". OK, so I read that I need to

Dim FormSomething aAS New Form1

then I can

FormSomething.TextBox1.Text = "Some text"

But, FormSomething is not the same form as Form1, I can't see the text.....
Is there a way around it or am I stuck?

Same thing about procedures on a form and I want to run them from a
different form or module, this I can, but if I use values from the form in
te proceure I get the wrong result.

If I on Form1 has code like this

sub get_Customer_Info ()
....
qeryString="SELECT * FROM Cust WHERE KID='" Me.txtKID.text "'"
...
end sub

And then I try to run this from Form2 with this code:
Dim newForm As New Form1
Form1.get_Cstomer_Info

The get_Cstomer_Info procdure wil run, but the value of txtKID.text will be the text you set at design time.

Please help me here, I'm a frustrated VS.NET newbie
Ronny

[Herfried K. Wagner [MVP]]

* "Armin Zingler" <az*******@freenet.de> scripsit:

The .NET Framework contains several hundreds (or thousands) of classes.
There is no reason why classes derived from System.Windows.Forms.Form have a
global, automatically created, automatic instancing and invisible variable
with the same name of the Form, whereas the other hundreds don't have such a
variable.

Mhm... In VB.NET 2004, default instances will be back.

;-)

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[R]

OK, I tried to make a module named modMain, in there I wrote:
Module modMain

Sub main()

Dim frm As New frmMain

frm.Show()

End Sub

End Module

Then I tried modMain as startup object and I saw the form for 1/10 of a
second before it closed. Same if I use Sub Main as startup.

What am I doing wrong?

Ronny

"Rick Mogstad" <ri**@NOSPAM.computetosuit.com> wrote in message
news:OK**************@tk2msftngp13.phx.gbl...

"R" <[e-mail]> wrote in message news:Tl****************@news4.e.nsc.no...

FormSomething.TextBox1.Text = "Some text"

But, FormSomething is not the same form as Form1, I can't see the text.....
Is there a way around it or am I stuck?
I assume that Form1 is your startup form? Perhaps use a sub Main as your

startup. The problem is that The form you see is a different instance than FormSomething. They are both of type Form1, but different instances. If you call the FormSomething.Show then you will see that FormSomething will pop up, and the text will be correct.

[Cor]

Hi Armin,

I do not answer messages with wrong times in future which are from countries
I cannot believe it is an accident.

I thought you had the same idea as me about this kind of things.

Cor

[Codemonkey]

Try,

----------------------------
Sub Main()

Dim frm As New frmMain

System.Windows.Forms.Application.Run(frm)

End Sub
----------------------------

This should show frmMain and keep that application running as long as
frmMain stays open.

HTH,

Trev.

"R" <[e-mail]> wrote in message news:Xj*****************@news4.e.nsc.no...

OK, I tried to make a module named modMain, in there I wrote:
Module modMain

Sub main()

Dim frm As New frmMain

frm.Show()

End Sub

End Module

Then I tried modMain as startup object and I saw the form for 1/10 of a
second before it closed. Same if I use Sub Main as startup.

What am I doing wrong?

Ronny

"Rick Mogstad" <ri**@NOSPAM.computetosuit.com> wrote in message
news:OK**************@tk2msftngp13.phx.gbl...

"R" <[e-mail]> wrote in message news:Tl****************@news4.e.nsc.no...

FormSomething.TextBox1.Text = "Some text"

But, FormSomething is not the same form as Form1, I can't see the text.....
Is there a way around it or am I stuck?
I assume that Form1 is your startup form? Perhaps use a sub Main as

your startup. The problem is

that The form you see is a different instance than FormSomething. They are both of type Form1,

but different instances. If you call the FormSomething.Show then you

will see that FormSomething

will pop up, and the text will be correct.

[Cor]

Hi Jan,

Very good answer to someone before he had sended the message, and than
someone from Norge, do you think that he can understand your question, it is
more something to point R first on the newsgroup .

microsoft.windowsxp.basics

Because I think that someone from Norge who cannot set his system time has
more on such an answer first.

:-)))

Cor

"Jan Tielens" <ja*@no.spam.please.leadit.be> schreef in bericht
news:ui**************@TK2MSFTNGP11.phx.gbl...

Check out following article:
http://tinyurl.com/el1

Working with Multiple Forms in Visual Basic .NET: Upgrading to .NET

Describes how working with multiple forms has changed from previous editions of Microsoft Visual Basic and illustrates several key techniques, including displaying a second form, changing the appearance of another form, and using a form as a dialog.

--
Greetz

Jan Tielens
________________________________
Read my weblog: http://weblogs.asp.net/jan
"R" <[e-mail]> wrote in message news:Tl****************@news4.e.nsc.no...

In the "good old days"... I used to put most of my code in different
modules, to keep it tidy, then it was no problem writing in a module like:
Form1.textbox1.text = "Some text"

or from a form

Form2.textbox1.text = me.textbox2.text

Now, in vb.net iI get an error saying "Reference to a non-shared member
requires an object reference". OK, so I read that I need to

Dim FormSomething aAS New Form1

then I can

FormSomething.TextBox1.Text = "Some text"

But, FormSomething is not the same form as Form1, I can't see the

text.....

Is there a way around it or am I stuck?

Same thing about procedures on a form and I want to run them from a
different form or module, this I can, but if I use values from the form in te proceure I get the wrong result.

If I on Form1 has code like this

sub get_Customer_Info ()
....
qeryString="SELECT * FROM Cust WHERE KID='" Me.txtKID.text "'"
...
end sub

And then I try to run this from Form2 with this code:
Dim newForm As New Form1
Form1.get_Cstomer_Info

The get_Cstomer_Info procdure wil run, but the value of txtKID.text will

be

the text you set at design time.

Please help me here, I'm a frustrated VS.NET newbie
Ronny

[Armin Zingler]

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> schrieb

* "Armin Zingler" <az*******@freenet.de> scripsit:

The .NET Framework contains several hundreds (or thousands) of
classes. There is no reason why classes derived from
System.Windows.Forms.Form have a global, automatically created,
automatic instancing and invisible variable with the same name of
the Form, whereas the other hundreds don't have such a variable.

Mhm... In VB.NET 2004, default instances will be back.

;-)

Yes, unfortunally. :-( Can we switch this off? Something like "Option
DoThingsUnderTheHoodThatIDontWant Off"?
--
Armin

[Cor]

> > Mhm... In VB.NET 2004, default instances will be back.

;-)

Yes, unfortunally. :-( Can we switch this off? Something like "Option
DoThingsUnderTheHoodThatIDontWant Off"?

Armin

I agree with Armin

Cor

[Cor]

Hi Codemonkey,

Did you not see the question is still not aked?

It is a question for the future, and therefore the answer has to wait.

Cor

[R]

Hmm, believe it or not, I wil have to check the time on my home PC.
Sorry, but what is the problem with wrong time?
Because the message stay on top for a log time?

Ronny

"Cor" <no*@non.com> wrote in message
news:%2***************@TK2MSFTNGP11.phx.gbl...

Hi Armin,

I do not answer messages with wrong times in future which are from countries I cannot believe it is an accident.

I thought you had the same idea as me about this kind of things.

Cor

[R]

Mobbe...

"Cor" <no*@non.com> wrote in message
news:uc**************@TK2MSFTNGP12.phx.gbl...

Hi Jan,

Very good answer to someone before he had sended the message, and than
someone from Norge, do you think that he can understand your question, it is more something to point R first on the newsgroup .

microsoft.windowsxp.basics

Because I think that someone from Norge who cannot set his system time has
more on such an answer first.

:-)))

Cor

"Jan Tielens" <ja*@no.spam.please.leadit.be> schreef in bericht
news:ui**************@TK2MSFTNGP11.phx.gbl...

Check out following article:
http://tinyurl.com/el1

Working with Multiple Forms in Visual Basic .NET: Upgrading to .NET

Describes how working with multiple forms has changed from previous editions

of Microsoft Visual Basic and illustrates several key techniques,

including

displaying a second form, changing the appearance of another form, and

using

a form as a dialog.

--
Greetz

Jan Tielens
________________________________
Read my weblog: http://weblogs.asp.net/jan
"R" <[e-mail]> wrote in message news:Tl****************@news4.e.nsc.no...

In the "good old days"... I used to put most of my code in different
modules, to keep it tidy, then it was no problem writing in a module like:
Form1.textbox1.text = "Some text"

or from a form

Form2.textbox1.text = me.textbox2.text

Now, in vb.net iI get an error saying "Reference to a non-shared member requires an object reference". OK, so I read that I need to

Dim FormSomething aAS New Form1

then I can

FormSomething.TextBox1.Text = "Some text"

But, FormSomething is not the same form as Form1, I can't see the

text.....

Is there a way around it or am I stuck?

Same thing about procedures on a form and I want to run them from a
different form or module, this I can, but if I use values from the

form in te proceure I get the wrong result.

If I on Form1 has code like this

sub get_Customer_Info ()
....
qeryString="SELECT * FROM Cust WHERE KID='" Me.txtKID.text "'"
...
end sub

And then I try to run this from Form2 with this code:
Dim newForm As New Form1
Form1.get_Cstomer_Info

The get_Cstomer_Info procdure wil run, but the value of txtKID.text

will be

the text you set at design time.

Please help me here, I'm a frustrated VS.NET newbie
Ronny

[Cor]

> Sorry, but what is the problem with wrong time?

Because the message stay on top for a log time?

Yes

[R]

OK, Cor, I see what you mean. You can wait until tomorrow with your answers.

To all who have answered:
Thank you very much, it vas really helpful.
I'm sorry for the date on my home PC. It seems to be 24 hours to fast, I
will fix it after work today.

Ronny
"Cor" <no*@non.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

Hi Codemonkey,

Did you not see the question is still not aked?

It is a question for the future, and therefore the answer has to wait.

Cor

[R]

"Cor" <no*@non.com> wrote in message
news:O7*************@TK2MSFTNGP12.phx.gbl...

Sorry, but what is the problem with wrong time?
Because the message stay on top for a log time?

Yes

It wil not happen again, I promise.

Ronny

[CJ Taylor]

Good option. =)

"Armin Zingler" <az*******@freenet.de> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> schrieb

* "Armin Zingler" <az*******@freenet.de> scripsit:

The .NET Framework contains several hundreds (or thousands) of
classes. There is no reason why classes derived from
System.Windows.Forms.Form have a global, automatically created,
automatic instancing and invisible variable with the same name of
the Form, whereas the other hundreds don't have such a variable.

Mhm... In VB.NET 2004, default instances will be back.

;-)

Yes, unfortunally. :-( Can we switch this off? Something like "Option
DoThingsUnderTheHoodThatIDontWant Off"?
--
Armin

[Jay B. Harlow [MVP - Outlook]]

Armin,

Yes, unfortunally. :-( Can we switch this off? Something like "Option
DoThingsUnderTheHoodThatIDontWant Off"?
Looking at the code that Whidbey generated, I saw no reason why you could
not remove the code that was being injected for the default instances.
Similar to how you can remove the code that is injected via VB6 Upgrade
Wizard.

As its straight VB.NET code in the "generated" section. However I did not
verify that it would not come back each time you modified the form. I would
hope MS is smart enough to only add the code when the form is created, not
whenever it is modified.

Note there is some "singleton" code and a custom attribute.

Having an option to turn it off, or a carefully crafted add-in to remove the
code later would be nice options...

Just a thought
Jay

"Armin Zingler" <az*******@freenet.de> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... "Herfried K. Wagner [MVP]" <hi***************@gmx.at> schrieb

* "Armin Zingler" <az*******@freenet.de> scripsit:

The .NET Framework contains several hundreds (or thousands) of
classes. There is no reason why classes derived from
System.Windows.Forms.Form have a global, automatically created,
automatic instancing and invisible variable with the same name of
the Form, whereas the other hundreds don't have such a variable.

Mhm... In VB.NET 2004, default instances will be back.

;-)

Yes, unfortunally. :-( Can we switch this off? Something like "Option
DoThingsUnderTheHoodThatIDontWant Off"?
--
Armin

[Sueffel]

"R" <[e-mail]> wrote in message news:Xj*****************@news4.e.nsc.no...

OK, I tried to make a module named modMain, in there I wrote:
Module modMain

Sub main()

Dim frm As New frmMain

frm.Show()

End Sub

End Module

Then I tried modMain as startup object and I saw the form for 1/10 of a
second before it closed. Same if I use Sub Main as startup.

What am I doing wrong?

Ronny

"Rick Mogstad" <ri**@NOSPAM.computetosuit.com> wrote in message
news:OK**************@tk2msftngp13.phx.gbl...

"R" <[e-mail]> wrote in message news:Tl****************@news4.e.nsc.no...

FormSomething.TextBox1.Text = "Some text"

But, FormSomething is not the same form as Form1, I can't see the text.....
Is there a way around it or am I stuck?
I assume that Form1 is your startup form? Perhaps use a sub Main as

your startup. The problem is

that The form you see is a different instance than FormSomething. They are both of type Form1,

but different instances. If you call the FormSomething.Show then you

will see that FormSomething

will pop up, and the text will be correct.

I know a little late, but I did notice something that I would like to point
out... Variable scope in this case is procedure level. So, frm is dead
after Sub Main finishes, that's why it was disappearing. Here's the
"proper" way of doing it, atleast that's what they say, there's about 20
different ways of doing the same damn thing! LOL

Module StartHere
public m_Form as frmMain

Sub New()
m_Form = New frmMain
m_Form.Show()
End Sub ' End of Sub New
End Module

BTW, I put that comment at the end of every things I do, it keeps things
straight in long functions :)

HTH
Sueffel
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.558 / Virus Database: 350 - Release Date: 1/2/2004

[Rob Richardson]

R,

In VB6, forms' Show() method took an argument to indicate whether the form
was to be modal or modeless. If the form was to be modal, the Show() method
would not end until the form was closed or hidden. If the form was
modeless, the Show() method would cause the form to be displayed and then
would return immediately. So in your code, the form is displayed, Show()
returns immediately, your form object goes out of scope, and the form
disappears. Making the form object a member of your module outside your
subroutine can work, if you really want a modeless form. But if you want a
modal form, so that after you come back from the Show() you know a user has
entered data, call ShowDialog() instead.

The following code will behave as you wanted your code to behave:

Module modMain

Sub main()

Dim frm As New frmMain

frm.ShowDialog()

End Sub

End Module

Now, could somebody please explain to me why VB.Net has the
Application.Run() method?

Rob

[Codemonkey]

> Did you not see the question is still not aked?

Nope, the date stamp in my reader reads "13/01/2004, 09:59" for the message
I replied to. Unless my watch and computer are wrong, that's todays date
isn't it?

"Cor" <no*@non.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

Hi Codemonkey,

Did you not see the question is still not aked?

It is a question for the future, and therefore the answer has to wait.

Cor

[Cor]

Hi codemonkey

I know it, it is to much for a monkey than to look furter than the node on
the tree he is sitting up.

No just joking R made it all clear, but this thread is stayed on top 24
hours.

:-)

Cor

[Codemonkey]

> Now, could somebody please explain to

me why VB.Net has the
Application.Run() method?
Application.Run is used to start a message loop, allowing your application
to process Windows messages from the operating system (e.g. Mouse Movements,
Key Presses etc.) Without this, your application won't function properly
(e.g. System.Windows.Forms.Timer won't work etc).

If you call Application.Run with a form as a parameter, it will show the
form and block the calling method until the form is closed (like ShowDialog,
except a proper message loop will be created).

If you set the startup object of your project to be the form itself, VB
automatically creates a hidden default Sub Main with a call to
Application.Run in it. Set a breakpoint in the "Sub New" of your startup
form and look at the call stack to confirm this (you may need to switch "Non
User Code" on to see it).

HTH,

Trev.

"Rob Richardson" <th*****@n2net.net> wrote in message
news:10*************@corp.supernews.com... R,

In VB6, forms' Show() method took an argument to indicate whether the form
was to be modal or modeless. If the form was to be modal, the Show() method would not end until the form was closed or hidden. If the form was
modeless, the Show() method would cause the form to be displayed and then
would return immediately. So in your code, the form is displayed, Show()
returns immediately, your form object goes out of scope, and the form
disappears. Making the form object a member of your module outside your
subroutine can work, if you really want a modeless form. But if you want a modal form, so that after you come back from the Show() you know a user has entered data, call ShowDialog() instead.

The following code will behave as you wanted your code to behave:

Module modMain

Sub main()

Dim frm As New frmMain

frm.ShowDialog()

End Sub

End Module

Now, could somebody please explain to me why VB.Net has the
Application.Run() method?

Rob

[Codemonkey]

lol. Pity about the "Modems" thread then. Roll on 2005 ;)

Crappy news servers. A "received time by the server" would be far more
useful than a sent time.

Trev
"Cor" <no*@non.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Hi codemonkey

I know it, it is to much for a monkey than to look furter than the node on
the tree he is sitting up.

No just joking R made it all clear, but this thread is stayed on top 24
hours.

:-)

Cor

[Codemonkey]

> Module StartHere

public m_Form as frmMain

Sub New()
m_Form = New frmMain
m_Form.Show()
End Sub ' End of Sub New
End Module
Am I right in assuming that "Sub New" be "Sub Main" above? If not, how do
you start this module when starting the program? If it is supposed to be
"Sub Main", then your solution won't work.
Variable scope in this case is procedure level.
So, frm is dead
after Sub Main finishes,
that's why it was disappearing
Let me attempt to explain why this isn't the case IMHO:

When "Sub Main" finishes, your program as a whole exits, so no matter the
scope of the form variable, it will not keep showing once "Sub Main" has
exited.

If you set your startup object to be the form, VB automatically creates an
invisible "Sub Main" in the background which is like the one below:

-----------------------

Sub Main()

Dim objForm as frmStartup = New frmStartup
System.windows.forms.application.run(objForm)

End Sub

-----------------------

The call to System.windows.forms.application.run() will start a message loop
(which is used by the form to catch windows messages and fire events (e.g.
Mouse Move, key presses etc.).

When Application.Run() is called with the form as a parameter, it shows the
form and blocks the calling procedure (in this case "Sub Main") until the
form exits.

If you need your own sub main, then use Application.Run to show the form.
This will prevent Sub Main from exiting until the form is closed.

HTH,

Trev.
"Sueffel" <so*****@somewhere.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
"R" <[e-mail]> wrote in message news:Xj*****************@news4.e.nsc.no...

OK, I tried to make a module named modMain, in there I wrote:
Module modMain

Sub main()

Dim frm As New frmMain

frm.Show()

End Sub

End Module

Then I tried modMain as startup object and I saw the form for 1/10 of a
second before it closed. Same if I use Sub Main as startup.

What am I doing wrong?

Ronny

"Rick Mogstad" <ri**@NOSPAM.computetosuit.com> wrote in message
news:OK**************@tk2msftngp13.phx.gbl...

"R" <[e-mail]> wrote in message news:Tl****************@news4.e.nsc.no... >
> FormSomething.TextBox1.Text = "Some text"
>
> But, FormSomething is not the same form as Form1, I can't see the text.....

>
> Is there a way around it or am I stuck?

I assume that Form1 is your startup form? Perhaps use a sub Main as your

startup. The problem is

that The form you see is a different instance than FormSomething.

They are both of type Form1,

but different instances. If you call the FormSomething.Show then you

will

see that FormSomething

will pop up, and the text will be correct.

I know a little late, but I did notice something that I would like to

point out... Variable scope in this case is procedure level. So, frm is dead
after Sub Main finishes, that's why it was disappearing. Here's the
"proper" way of doing it, atleast that's what they say, there's about 20
different ways of doing the same damn thing! LOL

Module StartHere
public m_Form as frmMain

Sub New()
m_Form = New frmMain
m_Form.Show()
End Sub ' End of Sub New
End Module

BTW, I put that comment at the end of every things I do, it keeps things
straight in long functions :)

HTH
Sueffel
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.558 / Virus Database: 350 - Release Date: 1/2/2004

[Sueffel]

"Codemonkey" <hu*********@hotmail.com> wrote in message
news:ua**************@tk2msftngp13.phx.gbl...

Module StartHere
public m_Form as frmMain

Sub New()
m_Form = New frmMain
m_Form.Show()
End Sub ' End of Sub New
End Module
Am I right in assuming that "Sub New" be "Sub Main" above? If not, how do
you start this module when starting the program? If it is supposed to be
"Sub Main", then your solution won't work.

Variable scope in this case is procedure level.
So, frm is dead
after Sub Main finishes,
that's why it was disappearing

Let me attempt to explain why this isn't the case IMHO:

When "Sub Main" finishes, your program as a whole exits, so no matter the
scope of the form variable, it will not keep showing once "Sub Main" has
exited.

If you set your startup object to be the form, VB automatically creates an
invisible "Sub Main" in the background which is like the one below:

-----------------------

Sub Main()

Dim objForm as frmStartup = New frmStartup
System.windows.forms.application.run(objForm)

End Sub

-----------------------

The call to System.windows.forms.application.run() will start a message

loop (which is used by the form to catch windows messages and fire events (e.g.
Mouse Move, key presses etc.).

When Application.Run() is called with the form as a parameter, it shows the form and blocks the calling procedure (in this case "Sub Main") until the
form exits.

If you need your own sub main, then use Application.Run to show the form.
This will prevent Sub Main from exiting until the form is closed.

HTH,

Trev.
"Sueffel" <so*****@somewhere.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

"R" <[e-mail]> wrote in message news:Xj*****************@news4.e.nsc.no...

OK, I tried to make a module named modMain, in there I wrote:
Module modMain

Sub main()

Dim frm As New frmMain

frm.Show()

End Sub

End Module

Then I tried modMain as startup object and I saw the form for 1/10 of a second before it closed. Same if I use Sub Main as startup.

What am I doing wrong?

Ronny

"Rick Mogstad" <ri**@NOSPAM.computetosuit.com> wrote in message
news:OK**************@tk2msftngp13.phx.gbl...
>
> "R" <[e-mail]> wrote in message news:Tl****************@news4.e.nsc.no... > >
> > FormSomething.TextBox1.Text = "Some text"
> >
> > But, FormSomething is not the same form as Form1, I can't see the
text.....
> >
> > Is there a way around it or am I stuck?
>
> I assume that Form1 is your startup form? Perhaps use a sub Main as

your

startup. The problem is
> that The form you see is a different instance than FormSomething. They are both of type Form1,
> but different instances. If you call the FormSomething.Show then

you will

see that FormSomething
> will pop up, and the text will be correct.
>
>

I know a little late, but I did notice something that I would like to

point

out... Variable scope in this case is procedure level. So, frm is dead
after Sub Main finishes, that's why it was disappearing. Here's the
"proper" way of doing it, atleast that's what they say, there's about 20
different ways of doing the same damn thing! LOL

Module StartHere
public m_Form as frmMain

Sub New()
m_Form = New frmMain
m_Form.Show()
End Sub ' End of Sub New
End Module

BTW, I put that comment at the end of every things I do, it keeps things
straight in long functions :)

HTH
Sueffel
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.558 / Virus Database: 350 - Release Date: 1/2/2004

Sorry, yes, it should be Sub Main, But my question is this... Why are you
openening a form from Sub Main like it was a console App? Why not just set
the project property to Windows Application and set the startup object to
frmMain? Otherwise, if you are deadset on the current way, you could try to
start a "Holder Thread" that will keep things in motion until you're done,
but I don't see a need for the added overhead.

HTH
Sueffel


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.558 / Virus Database: 350 - Release Date: 1/2/2004

[Codemonkey]

> Sorry, yes, it should be Sub Main,
Well, in that case, the form will still close immediatly with your example,
regardless of the scope of the variable.

But my question is this... Why are you
openening a form from Sub Main like it was
a console App?
Some applications like to do initialization before showing a form. Also,
some windows forms applications take command line arguments (e.g. notepad
can open a file by passing it as a command line argument). There are other
ways of getting command line args, but Sub Main is generally the easiest.
Sometimes, splash screens are shown and hidden from the Sub Main.

For example, I tend to structure my Windows Forms Sub Main like this:
---------------

Sub Main(args() as String)
1. Show a splash screen

2. Load any configuration settings

3. Load any data needed

4. Hide the splash screen

5. Show the main MDI form
System.Windows.Forms.Application.Run(new frmMDI)

6. When we get here, the application exits.

End Sub

---------------
Otherwise, if you are deadset on the current
way, you could try to start a "Holder Thread"
that will keep things in motion until you're done,
but I don't see a need for the added overhead.
This is pretty much Application.Run does (instead of starting a thread and
blocking until it exits, it creates a message loop and blocks the calling
function). You need a message loop to allow your form to catch mouse
movements and other events.
Why not just set the project property to
Windows Application and set the startup object to
frmMain?

If you do this, VB automatically creates a hidden Sub Main with a call to
Application.Run, so the overhead difference is not applicable, but you loose
out the advantages mentioned above.

HTH,

Trev.

[Sueffel]

"Codemonkey" <hu*********@hotmail.com> wrote in message
news:ut**************@tk2msftngp13.phx.gbl...

Sorry, yes, it should be Sub Main,

Well, in that case, the form will still close immediatly with your

example, regardless of the scope of the variable.

But my question is this... Why are you
openening a form from Sub Main like it was
a console App?
Some applications like to do initialization before showing a form. Also,
some windows forms applications take command line arguments (e.g. notepad
can open a file by passing it as a command line argument). There are other
ways of getting command line args, but Sub Main is generally the easiest.
Sometimes, splash screens are shown and hidden from the Sub Main.

For example, I tend to structure my Windows Forms Sub Main like this:
---------------

Sub Main(args() as String)
1. Show a splash screen

2. Load any configuration settings

3. Load any data needed

4. Hide the splash screen

5. Show the main MDI form
System.Windows.Forms.Application.Run(new frmMDI)

6. When we get here, the application exits.

End Sub

---------------

Otherwise, if you are deadset on the current
way, you could try to start a "Holder Thread"
that will keep things in motion until you're done,
but I don't see a need for the added overhead.

This is pretty much Application.Run does (instead of starting a thread and
blocking until it exits, it creates a message loop and blocks the calling
function). You need a message loop to allow your form to catch mouse
movements and other events.

Why not just set the project property to
Windows Application and set the startup object to
frmMain?

If you do this, VB automatically creates a hidden Sub Main with a call to
Application.Run, so the overhead difference is not applicable, but you

loose out the advantages mentioned above.

HTH,

Trev.

I'm still not understanding becuase you can either Override the Base Sub
Main, or in the Sub New, under InitializeComponents() or even right above
it, you can do everything you just described to be. I'm not trying to be
pushy, just trying to understand where you're coming from and making my
suggestions on it. And honestly, I put the CommandLineArgs in as part of
the Overriden Sub New(), as the class is created and initialized, it's doing
exactly what I need it to do. I know, the way I'm discribing is not perfect
in books, but in practice it has served me well, and I'm very found of
saying there's atleast 3 solutions to every problem, and this is the one I
prefer to use and convey onto you.

HTH
Sueffel
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.558 / Virus Database: 350 - Release Date: 1/2/2004

[Sueffel]

"Codemonkey" <hu*********@hotmail.com> wrote in message
news:ut**************@tk2msftngp13.phx.gbl...

Sorry, yes, it should be Sub Main,

Well, in that case, the form will still close immediatly with your

example, regardless of the scope of the variable.

But my question is this... Why are you
openening a form from Sub Main like it was
a console App?
Some applications like to do initialization before showing a form. Also,
some windows forms applications take command line arguments (e.g. notepad
can open a file by passing it as a command line argument). There are other
ways of getting command line args, but Sub Main is generally the easiest.
Sometimes, splash screens are shown and hidden from the Sub Main.

For example, I tend to structure my Windows Forms Sub Main like this:
---------------

Sub Main(args() as String)
1. Show a splash screen

2. Load any configuration settings

3. Load any data needed

4. Hide the splash screen

5. Show the main MDI form
System.Windows.Forms.Application.Run(new frmMDI)

6. When we get here, the application exits.

End Sub

---------------

Otherwise, if you are deadset on the current
way, you could try to start a "Holder Thread"
that will keep things in motion until you're done,
but I don't see a need for the added overhead.

This is pretty much Application.Run does (instead of starting a thread and
blocking until it exits, it creates a message loop and blocks the calling
function). You need a message loop to allow your form to catch mouse
movements and other events.

Why not just set the project property to
Windows Application and set the startup object to
frmMain?

If you do this, VB automatically creates a hidden Sub Main with a call to
Application.Run, so the overhead difference is not applicable, but you

loose out the advantages mentioned above.

HTH,

Trev.

Sorry, didn't touch on the splash screen... I have one, it's opened in the
Sub Main() function, which also hides the main form, then the Splash form
does all the stuff like loading Config's, updating files, etc, then calls a
public method on the main form which fades out the splash form and fades in
the main form. I do this by having:
Protected m_CallForm as frmMain

Sub Main(ByVal CallForm as frmMain)
m_CallForm=CallForm
End Sub

Private Sub Form1_Load({blah blah blah}) handles MyBase.Load
{Do all the stuff I need to}
m_CallForm.KillSplash(True)
End Sub

Like I said, there's probably a "better" or "proper" way of doing this, but
this works, and for all those out there that ask, "Why do you need to use
Opacity and Transparency in a Business App?". My Answer, "To have a nifty,
borderless, shaped form for my splash form that fades in and out and just
makes things a little bit more nifty and says that 'Hey, here's my
program!'"
I like to throw lil nifty things into my code to set my programs apart......

Sueffel
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.558 / Virus Database: 350 - Release Date: 1/2/2004

[Codemonkey]

Sorry, didn't touch on the splash screen... I have one, it's opened in the Sub Main() function, which also hides the main form, then the Splash form
does all the stuff like loading Config's, updating files, etc, then calls a public method on the main form which fades out the splash form and fades in the main form. I do this by having:
Protected m_CallForm as frmMain

Sub Main(ByVal CallForm as frmMain)
m_CallForm=CallForm
End Sub

Private Sub Form1_Load({blah blah blah}) handles MyBase.Load
{Do all the stuff I need to}
m_CallForm.KillSplash(True)
End Sub

I take it then that your splash form is the startup object of your project?
If it is, all is fine, but I think your naming of "Sub Main()" might be a
bit confusing - IMHO, there should only ever be one "Sub Main" in an
application - the one the operating system calls when starting your
application. This inclides the hidden one when starting your application
from a form.

Like I said, there's probably a "better" or "proper" way of doing this, but this works
That wasn't really my origional point - I was trying to help get the point
across that "Sub Main" is the entry point in all applications. When you set
a form as a startup, VB creates the Sub Main in the background and
automatically calls Application.Run to make it visible. When you provide
your own Sub Main, you need to call Application.Run to show a form without
having it disappear after it has been shown.

I like to throw lil nifty things into my code to set my programs

apart......

lol. Don't we all ;)

[Tom Leylan]

"Sueffel" <so*****@somewhere.com> wrote...

"Codemonkey" <hu*********@hotmail.com> wrote...

Sub Main(args() as String)
1. Show a splash screen
2. Load any configuration settings
3. Load any data needed
4. Hide the splash screen
5. Show the main MDI form
6. When we get here, the application exits.
End Sub

I'm still not understanding becuase you can either Override the Base Sub
Main, or in the Sub New, under InitializeComponents() or even right above
it, you can do everything you just described to be.

Sueffel,

I think you may be overlooking the "elegance" angle. The elegance of the
code isn't a side-effect of being "tricky" but rather of being plain and
obvious. And "reusability" is an added bonus :-)

If you look at Trev's example... you can use it as a basic model regardless
of what you might need to do on startup. If you need a password screen that
can be inserted. Granted you can add a password to the main form but that
loads the main form before the password has been confirmed. A big deal?
Probably not but why load the main form if the password fails?

It can also run an app (a process perhaps) without a form at all. And it
can determine which of two (or more) forms to load depending upon a switch.
That switch can be provided on the command line or as a result of of the
password "clearance level" (or whatever else.)

If part of the "load any data needed" step checks to see if the system is
"down for maintenance" a small dialog form can be loaded to inform the
user... possibly in place of the login form. Again (of course) the main
form can handle this and everything else but I ask why put the burden there?

But it isn't these examples that make it elegant, it is the idea that so
many variations can be handled (including these) so elegantly that makes it
a good choice. I'll point out that in your followup message your main form
(I'm pretty certain) is given the responsibility for clearing the splash
screen. Not horrible but again, that doesn't happen in Trev's example and
as I point out... there may be a splash screen and (in the case of a server
app) no main screen.

Take another moment to review the concept and I think you'll Trev's solution
is very clear and to the point.
Tom

[Herfried K. Wagner [MVP]]

* "Armin Zingler" <az*******@freenet.de> scripsit:

The .NET Framework contains several hundreds (or thousands) of
classes. There is no reason why classes derived from
System.Windows.Forms.Form have a global, automatically created,
automatic instancing and invisible variable with the same name of
the Form, whereas the other hundreds don't have such a variable.

Mhm... In VB.NET 2004, default instances will be back.

;-)

Yes, unfortunally. :-( Can we switch this off? Something like "Option
DoThingsUnderTheHoodThatIDontWant Off"?

AFAIS it will only implement sort of singleton pattern, so it won't
cause the app to use a lot of memory if you don't access the controls by
name.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Codemonkey]

> Take another moment to review the concept

and I think you'll Trev's solution
is very clear and to the point.

Thanks for the kind words. If only all my code was this clear ;)

I started using this method of loading an app mainly because of the
flexibility, but also partly because I'm a big believer in not letting VB do
too much behind the scenes (like creating the hidden Sub Main). For me, when
VB does stuff I don't know about, it makes it harder for me to follow when
debugging.

On that note, there has been talk in this thread about bringing back default
instances of Forms. Althugh I do create default instances myself sometimes
(mainly for MDI parent forms), IMHO, it's just another thing that I don't
want VB to do in the backgorund.

Best Regards,

Trev.

[Tom Leylan]

"Codemonkey" <hu*********@hotmail.com> wrote...

Take another moment to review the concept
and I think you'll Trev's solution
is very clear and to the point.
Thanks for the kind words. If only all my code was this clear ;)

Well it wouldn't be fair to the rest of us if everything was this clear...
I started using this method of loading an app mainly because of the
flexibility, but also partly because I'm a big believer in not letting VB do too much <snip>
No argument from me on this.
On that note, there has been talk in this thread about bringing back default instances of Forms. Althugh I do create default instances myself sometimes
(mainly for MDI parent forms), IMHO, it's just another thing that I don't
want VB to do in the backgorund.

I could see an argument for automatic stuff if it was particularly hard to
implement such things manually but in this case it not only isn't difficult,
it is at least as easy and gives one added control.

Tom

[Codemonkey]

> I could see an argument for automatic

stuff if it was particularly hard to
implement such things manually

I suppose I could make an exception for Generics (in the next version of
..net). Although inheritance has made custom collections a lot easier to
implement in vb, it still takes a lot of repetative work to accomplish. I'd
be more than happy for the compiler to take this off my hands (as long as I
have a fair idea of what it's doing).

Trev.

[Sueffel]

"Tom Leylan" <ge*@iamtiredofspam.com> wrote in message
news:eZ**************@TK2MSFTNGP09.phx.gbl...

"Sueffel" <so*****@somewhere.com> wrote...

"Codemonkey" <hu*********@hotmail.com> wrote...

Sub Main(args() as String)
1. Show a splash screen
2. Load any configuration settings
3. Load any data needed
4. Hide the splash screen
5. Show the main MDI form
6. When we get here, the application exits.
End Sub

I'm still not understanding becuase you can either Override the Base Sub
Main, or in the Sub New, under InitializeComponents() or even right

above it, you can do everything you just described to be.

Sueffel,

I think you may be overlooking the "elegance" angle. The elegance of the
code isn't a side-effect of being "tricky" but rather of being plain and
obvious. And "reusability" is an added bonus :-)

If you look at Trev's example... you can use it as a basic model

regardless of what you might need to do on startup. If you need a password screen that can be inserted. Granted you can add a password to the main form but that
loads the main form before the password has been confirmed. A big deal?
Probably not but why load the main form if the password fails?

It can also run an app (a process perhaps) without a form at all. And it
can determine which of two (or more) forms to load depending upon a switch. That switch can be provided on the command line or as a result of of the
password "clearance level" (or whatever else.)

If part of the "load any data needed" step checks to see if the system is
"down for maintenance" a small dialog form can be loaded to inform the
user... possibly in place of the login form. Again (of course) the main
form can handle this and everything else but I ask why put the burden there?
But it isn't these examples that make it elegant, it is the idea that so
many variations can be handled (including these) so elegantly that makes it a good choice. I'll point out that in your followup message your main form (I'm pretty certain) is given the responsibility for clearing the splash
screen. Not horrible but again, that doesn't happen in Trev's example and
as I point out... there may be a splash screen and (in the case of a server app) no main screen.

Take another moment to review the concept and I think you'll Trev's solution is very clear and to the point.
Tom

My Main form is the Entry point, with the splash screen as a secondary. At
one point I considered doing it the way the you discribed and Codemonkey is
trying, but I ran into the same problem of the application ceasing after the
code in Sub Main() is complete. I see a hundred different advantages, like
you pointed out, but after 2 hours of trying, I deemed it more effort than
it was worth and went with my current method. I'm going to spend an hour or
two and try it again, and let's see what I can produce.

Sueffel

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.558 / Virus Database: 350 - Release Date: 1/2/2004

[Sueffel]

"Sueffel" <so*****@somewhere.com> wrote in message
news:eV*************@TK2MSFTNGP11.phx.gbl...

"Tom Leylan" <ge*@iamtiredofspam.com> wrote in message
news:eZ**************@TK2MSFTNGP09.phx.gbl...

"Sueffel" <so*****@somewhere.com> wrote...

"Codemonkey" <hu*********@hotmail.com> wrote...

> Sub Main(args() as String)
> 1. Show a splash screen
> 2. Load any configuration settings
> 3. Load any data needed
> 4. Hide the splash screen
> 5. Show the main MDI form
> 6. When we get here, the application exits.
> End Sub

I'm still not understanding becuase you can either Override the Base Sub Main, or in the Sub New, under InitializeComponents() or even right above it, you can do everything you just described to be.

Sueffel,

I think you may be overlooking the "elegance" angle. The elegance of the code isn't a side-effect of being "tricky" but rather of being plain and
obvious. And "reusability" is an added bonus :-)

If you look at Trev's example... you can use it as a basic model

regardless

of what you might need to do on startup. If you need a password screen

that

can be inserted. Granted you can add a password to the main form but that loads the main form before the password has been confirmed. A big deal?
Probably not but why load the main form if the password fails?

It can also run an app (a process perhaps) without a form at all. And it can determine which of two (or more) forms to load depending upon a

switch.

That switch can be provided on the command line or as a result of of the
password "clearance level" (or whatever else.)

If part of the "load any data needed" step checks to see if the system is "down for maintenance" a small dialog form can be loaded to inform the
user... possibly in place of the login form. Again (of course) the main
form can handle this and everything else but I ask why put the burden

there?

But it isn't these examples that make it elegant, it is the idea that so
many variations can be handled (including these) so elegantly that makes

it

a good choice. I'll point out that in your followup message your main

form

(I'm pretty certain) is given the responsibility for clearing the splash
screen. Not horrible but again, that doesn't happen in Trev's example and as I point out... there may be a splash screen and (in the case of a

server

app) no main screen.

Take another moment to review the concept and I think you'll Trev's

solution

is very clear and to the point.
Tom

My Main form is the Entry point, with the splash screen as a secondary.

At one point I considered doing it the way the you discribed and Codemonkey is trying, but I ran into the same problem of the application ceasing after the code in Sub Main() is complete. I see a hundred different advantages, like you pointed out, but after 2 hours of trying, I deemed it more effort than
it was worth and went with my current method. I'm going to spend an hour or two and try it again, and let's see what I can produce.

Sueffel

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.558 / Virus Database: 350 - Release Date: 1/2/2004

Here is what I've found:

1) Project must be in WindowsApplication mode, and Startup is either Module1
(For My code ) or Sub Main.

2) The following code works.
Imports System.Windows.Forms
Module Module1
Sub Main()
Application.Run(New Form1())
End Sub
End Module
Class Form1
Inherits System.Windows.Forms.Form
Sub New()
MyBase.New()
End Sub
End Class

The problem's I was having before was I didn't use Application.Run, and, I
had it set to a Console Application. Now I see the errors, and I can
redesign my Applications the way I origionally wanted them to be done.

Sueffel