VB6 vs VB .NET

[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]

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.

 

[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.

 

[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

 

[Sueffel]

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.


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.

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

 

[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]

Well, in that case, the form will still close immediatly with your example,
regardless of the scope of the variable.



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

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


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.


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

 

[Sueffel]

Well, in that case, the form will still close immediatly with your example,
regardless of the scope of the variable.



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

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


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.


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

 

[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]

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]]

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.

 

[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.

 

[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

 

[Tom Leylan]

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]

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

 

[Sueffel]

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

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