What file should the New sub be put into?

  • Thread starter Thread starter Academia
  • Start date Start date
A

Academia

I believe that with VS2005 if I don't include sub New it is somehow added
but not visible.

But if I need a New with arguments or if I have to insert code into New I
can write my own.

Should it be put into the .designer.vb or into the .vb file?

If you recommend putting it into the .vb file should it be:

Public Sub New()

MyBase.New()

InitializeComponent()

'my code here

End Sub



or can I call the one that was somehow added?



Public Sub New()

CallDefaultNew() 'somehow

'my code here

End Sub



Guess I'm trying to divorce my code from the .designer.vb code which could
change some day. (Suppose they decide to call InitializeComponent something
else.)
 
I believe that with VS2005 if I don't include sub New it is somehow added
but not visible.

But if I need a New with arguments or if I have to insert code into New I
can write my own.

Should it be put into the .designer.vb  or into the .vb file?

If you recommend putting it into the .vb file should it be:

Public Sub New()

MyBase.New()

InitializeComponent()

'my code here

End Sub

or can I call the one that was somehow added?

Public Sub New()

CallDefaultNew() 'somehow

'my code here

End Sub

Guess I'm trying to divorce my code from the .designer.vb code which could
change some day. (Suppose they decide to call InitializeComponent something
else.)
Click to expand...

I saw that code generated by default in an app follows as:

#Region " Windows Form Designer generated code "

Public Sub New()
MyBase.New()

'This call is required by the Windows Form Designer.
InitializeComponent()

'Add any initialization after the InitializeComponent() call

End Sub

I think you should past this step and do your stuff as coding and
designing both.
More suggestions would be better.
 
I believe that with VS2005 if I don't include sub New it is somehow added
but not visible.

But if I need a New with arguments or if I have to insert code into New I
can write my own.

Should it be put into the .designer.vb  or into the .vb file?

If you recommend putting it into the .vb file should it be:

Public Sub New()

MyBase.New()

InitializeComponent()

'my code here

End Sub

or can I call the one that was somehow added?

Public Sub New()

CallDefaultNew() 'somehow

'my code here

End Sub

Guess I'm trying to divorce my code from the .designer.vb code which could
change some day. (Suppose they decide to call InitializeComponent something
else.)
Click to expand...

Also you can visit that sites:
http://www.vbinfozine.com/a_disposable_comp.shtml
http://www.developerfusion.co.uk/show/4369/

and take a look at constructors:
http://www.startvbdotnet.com/oop/constructor.aspx

Hope these help.
 
Academia said:
I believe that with VS2005 if I don't include sub New it is somehow
added but not visible.
Click to expand...

If you don't add it then you'll get a default Public constructor that takes
no parameters and performs any default initialisation required by your
class. (Which is generally nothing for a general class, or calling into the
form initialisation code for a form).
Should it be put into the .designer.vb or into the .vb file?
Click to expand...

I always put it in the .vb file. The .designer.vb file is for auto-generated
code, the .vb file for user-generated code. The content of the constructor
will be your own code, so put it in the .vb file.
If you recommend putting it into the .vb file should it be:

Public Sub New()
MyBase.New()
InitializeComponent()
'my code here
End Sub
Click to expand...

(For a form) Yes. If you type on a blank line the following:

\\\
Public Sub New
///

....and press Return, you'll see that VB automatically adds all that code in
for you, so you can just add your own code where it indicates.

HTH,
 
Yes, VB creates a Public Sub New() if you don't explicitly have one.
If you want one, put it in your .vb file.

My experience has been that when I type: Public Sub New()
Intellisense enters all of the other lines too.
 
(O)enone said:
If you don't add it then you'll get a default Public constructor that
takes no parameters and performs any default initialisation required by
your class. (Which is generally nothing for a general class, or calling
into the form initialisation code for a form).


I always put it in the .vb file. The .designer.vb file is for
auto-generated code, the .vb file for user-generated code. The content of
the constructor will be your own code, so put it in the .vb file.


(For a form) Yes. If you type on a blank line the following:

\\\
Public Sub New
///

...and press Return, you'll see that VB automatically adds all that code
in for you, so you can just add your own code where it indicates.
Click to expand...

Guess I cut and paste so much I never saw this.
thanks
 
thanks for the info

I believe that with VS2005 if I don't include sub New it is somehow added
but not visible.

But if I need a New with arguments or if I have to insert code into New I
can write my own.

Should it be put into the .designer.vb or into the .vb file?

If you recommend putting it into the .vb file should it be:

Public Sub New()

MyBase.New()

InitializeComponent()

'my code here

End Sub

or can I call the one that was somehow added?

Public Sub New()

CallDefaultNew() 'somehow

'my code here

End Sub

Guess I'm trying to divorce my code from the .designer.vb code which could
change some day. (Suppose they decide to call InitializeComponent
something
else.)
Click to expand...

Also you can visit that sites:
http://www.vbinfozine.com/a_disposable_comp.shtml
http://www.developerfusion.co.uk/show/4369/

and take a look at constructors:
http://www.startvbdotnet.com/oop/constructor.aspx

Hope these help.
 
thanks a lot
Jack Jackson said:
Yes, VB creates a Public Sub New() if you don't explicitly have one.
If you want one, put it in your .vb file.

My experience has been that when I type: Public Sub New()
Intellisense enters all of the other lines too.
Click to expand...
 
Academia,

If you want this, then my anser is the same as (O)enOne, however I am
curious why you want this.

Mostly is just setting everything in the load event much easier to maintain
afterwards.

Cor
 
Cor said:
If you want this, then my anser is the same as (O)enOne, however I am
curious why you want this.

Mostly is just setting everything in the load event much easier to
maintain afterwards.
Click to expand...

Generally I agree, the Load event is a more intuitive place.

However, there are three instances I've found overriding the constructor to
be useful:

1. You want a scope that isn't Public (Friend, most likely), to prevent
external apps from creating an instance of the form.

2. You want to force the user of the form to provide certain values, so you
parameterise the constructor.

3. The Form_Load event seems to fire after the form has actually been
displayed. If you need to perform any form position/size operations, this
causes a visible flicker in the Load event. In the constructor this is
guaranteed to happen before the form becomes visible.
 
3. The Form_Load event seems to fire after the form has actually been
displayed. If you need to perform any form position/size operations, this
causes a visible flicker in the Load event. In the constructor this is
guaranteed to happen before the form becomes visible.
Click to expand...
No it is not, it happens as the form loads before that it is showed
(although you can force that)

Cor
 
(O)enone

I was focused so on that wrong behaviour of the Form_Load event that I did
not pay attention to the two first.
1. You want a scope that isn't Public (Friend, most likely), to prevent
external apps from creating an instance of the form.
Click to expand...

I really don't understand what you mean with the one above
2. You want to force the user of the form to provide certain values, so
you parameterise the constructor.
Click to expand...

This can be done by any property, after the construction.

(I don't say not to use overlaoded constructors, however only that they are
not direct visible as the load event is.)

In C# the overloaded constructor makes for me more sense because I can do
there
new TheClass(Parameter).TheMethod();

If somebody knows the equivalent in VB then I will be pleased.

Cor
 
..snip..
...snip

I want the forms to be forced to provide a value to the usercontrol.

I need to do something so the unparameterized constructor can not be
called by the form.

Would checking design mode be a good way or maybe adding a Private
unparameterized constructor (along with the parameterized the
constructor)would work .

Any suggestions?
 
Cor said:
I really don't understand what you mean with the one above
Click to expand...

If you think back to the old "PublicNotCreatable" instancing mode in VB6,
that's what I mean. It means that your form itself is public and a project
that references your assembly can see it and its properties, but the
referencing project won't be able to create an instance of the form as it is
unable to access the Friend-scope constructor.

This is much more likely to be applied to a standard class than a form, but
it's still valid for forms and still a reasonable situation.
This can be done by any property, after the construction.
Click to expand...

Indeed, but sometimes you want to force a value to be provided and then it
can be useful to parameterise the constructor. I have a number of classes in
my project (again, they're not forms as it happens, but the same principal
applies) that fundamentally require a reference to an object in my
framework, and so I parameterise the constructors to ensure that an object
instance is always available -- even in the constructor code itself.
No it is not, it happens as the form loads before that it is showed
(although you can force that)
Click to expand...

Hmm, having gone and specifically tried it, you're right. I definitely have
had issues with flickering when positioning the form that were resolved by
positioning it during the constructor rather than the Form_Load event. I'll
have to go back and try to work out what was going on there.

Actually, having had this discussion, I think I prefer using the class
constructor to Form.Load, simply because it's consistent with other
(non-Form) classes. I think to a certain extent it's maybe just down to
personal preference. Certainly in VB6 I would always have used the Form.Load
event...
 
Academia said:
I want the forms to be forced to provide a value to the usercontrol.

I need to do something so the unparameterized constructor can not be
called by the form.

Would checking design mode be a good way or maybe adding a Private
unparameterized constructor (along with the parameterized the
constructor)would work .
Click to expand...

If you add a parameterised constructor as the only constructor within the
class, that will be the only constructor your form offers, so the user of
your class will be forced to pass in the value. The default public
parameterless constructor will disappear as soon as you explicitly define a
constructor of any type.
 
(O)enone said:
If you add a parameterised constructor as the only constructor within the
class, that will be the only constructor your form offers, so the user of
your class will be forced to pass in the value. The default public
parameterless constructor will disappear as soon as you explicitly define
a constructor of any type.
Click to expand...

Doesn't the Designer need a unparameterized constructor?
Does the default one only disappear for the class user but not for the
Designer?

thanks
 
I have a number of classes in
my project (again, they're not forms as it happens, but the same principal
applies)
Click to expand...

I am definitly writing here about a form, other classes don't have a
form_load event.

In non form classes I use often overloaded constructors, because in that
place there are no documentation (maintenance) problems.

Cor
 
I am definitly writing here about a form, other classes don't have a
form_load event.
Click to expand...

BWAHAHAHAHA! Not even forms have a form_load event, dipstick.

A form named "form" will have a private form_Load sub-procedure that handles
the form's Load event.

And you're an expert, yes?
 
Guru said:
BWAHAHAHAHA! Not even forms have a form_load event, dipstick.

A form named "form" will have a private form_Load sub-procedure that
handles the form's Load event.

And you're an expert, yes?
Click to expand...

Actually I think he was copying the naming scheme that I put in my prior
message, so you can call me a dipstick instead if you like.

But the intention of the message was clear. I'll go with a post I just read
in another thread and assume that you are indeed a troll.
 
(O)enone said:
Actually I think he was copying the naming scheme that I put in my prior
message, so you can call me a dipstick instead if you like.
Click to expand...

Oh, no. I wouldn't do such a thing. He's an alleged expert and deserves it.
But the intention of the message was clear. I'll go with a post I just
read in another thread and assume that you are indeed a troll.
Click to expand...

An exceedingly capable and knowledgeable troll, thank you very muchly.
 
Back
Top