proper place for a variable

[Frank]

Hello,
I need one specific value in all the applicationspecific forms and classes
of my application. What is the proper place to put it? At the moment I use a
module with a public constant and that seems to be a handy place. Passing it
as a parameter doesn't seem to be very efficient. What do you suggest?
Thanks
Frank

[Peter van der Goes]

"Frank" <fr***@frank.com> wrote in message
news:cc**********@news3.tilbu1.nb.home.nl...

Hello,
I need one specific value in all the applicationspecific forms and classes
of my application. What is the proper place to put it? At the moment I use a module with a public constant and that seems to be a handy place. Passing it as a parameter doesn't seem to be very efficient. What do you suggest?
Thanks
Frank

I'm sure others will have contrasting opinions, but here goes...
Even though allowing global variables is a decidedly non-OO feature brought
forward from previous VB versions, I would be very tempted to do exactly as
you are now doing. I would not agree if it were a variable instead of a
named constant, but I see no harm in a global named constant.

--
Peter [MVP Visual Developer]
Jack of all trades, master of none.

[One Handed Man \( OHM - Terry Burns \)]

Remember, a module is a 'Sealed' Class which in imported automatically, all
members and properties are 'Shared'.

Personally, I avoid Modules and perfer to explicitly use Classes, this
avoids all the confusion surrounding Modules.

HTH

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

"Peter van der Goes" <p_**********@toadstool.u> wrote in message
news:Oi*************@TK2MSFTNGP11.phx.gbl...

"Frank" <fr***@frank.com> wrote in message
news:cc**********@news3.tilbu1.nb.home.nl...

Hello,
I need one specific value in all the applicationspecific forms and classes of my application. What is the proper place to put it? At the moment I

use a

module with a public constant and that seems to be a handy place.

Passing it

as a parameter doesn't seem to be very efficient. What do you suggest?
Thanks
Frank

I'm sure others will have contrasting opinions, but here goes...
Even though allowing global variables is a decidedly non-OO feature

brought forward from previous VB versions, I would be very tempted to do exactly as you are now doing. I would not agree if it were a variable instead of a
named constant, but I see no harm in a global named constant.

--
Peter [MVP Visual Developer]
Jack of all trades, master of none.

[One Handed Man \( OHM - Terry Burns \)]

You should declare your public constants in a class, lets GLOBALS

Public Class GLOBALS

Public Const PI As Double = 3.142

End Class
Dim a As Double = GLOBALS.PI

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

"Frank" <fr***@frank.com> wrote in message
news:cc**********@news3.tilbu1.nb.home.nl...

Hello,
I need one specific value in all the applicationspecific forms and classes
of my application. What is the proper place to put it? At the moment I use a module with a public constant and that seems to be a handy place. Passing it as a parameter doesn't seem to be very efficient. What do you suggest?
Thanks
Frank

[Herfried K. Wagner [MVP]]

* "Frank" <fr***@frank.com> scripsit:

I need one specific value in all the applicationspecific forms and classes
of my application. What is the proper place to put it? At the moment I use a
module with a public constant and that seems to be a handy place. Passing it
as a parameter doesn't seem to be very efficient. What do you suggest?

I suggest a friend module that provides the variables and constants.

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

[Herfried K. Wagner [MVP]]

* "One Handed Man \( OHM - Terry Burns \)" <news.microsoft.com> scripsit:

Remember, a module is a 'Sealed' Class which in imported automatically, all
members and properties are 'Shared'.

Personally, I avoid Modules and perfer to explicitly use Classes, this
avoids all the confusion surrounding Modules.

What confusions?!

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

[One Handed Man \( OHM - Terry Burns \)]

I didnt say you were confused, however, a lot of people seem to be.

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:uS*************@TK2MSFTNGP12.phx.gbl...

* "One Handed Man \( OHM - Terry Burns \)" <news.microsoft.com> scripsit:

Remember, a module is a 'Sealed' Class which in imported automatically, all members and properties are 'Shared'.

Personally, I avoid Modules and perfer to explicitly use Classes, this
avoids all the confusion surrounding Modules.

What confusions?!

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

[Cor Ligthert]

Hi Frank,

I prefer a class with shared members.

And before the others say it, that is the same as a module, however I never
use a module.

Cor

[Frank]

Ok, a class with globals it is.
Thanks for your opinions.
Fra
"Cor Ligthert" <no**********@planet.nl> wrote in message
news:OU**************@TK2MSFTNGP12.phx.gbl...

Hi Frank,

I prefer a class with shared members.

And before the others say it, that is the same as a module, however I never use a module.

Cor

[Les Hughes]

I encounter this problem quite a lot, and usually use a class with
shared members as shown above. Something as simple such as

Class myData

public shared strSetting as string = ""
public shared intWhatever as integer = 0

End Class

then just access your data via myData.*

Although shared values arent really true OO either, they are much closer
than modules IMO, and I tend to stay away from modules as much as possible.


Cor Ligthert wrote:

Hi Frank,

I prefer a class with shared members.

And before the others say it, that is the same as a module, however I never
use a module.

Cor

[Samuel L Matzen]

There are a number of issues here:

1. There really isn't a good OO place to put what we used to call "header
files". From what I can tell the community has pretty much decided that
putting them in shared properties or fields of a class. This seems to work
fine and from what I can see has no ill effects.

2. In general the VB.NET community is familiar with modules which as I
understand it are converted to classes with all of the members shared when
the IL is created. And, since modules are a "standard" part of VB I don't
see any reason they shouldn't be used.

IMHO putting "global" constants in either a module, or as shared members of
a class is quite acceptable. For those solutions where there are multiple
projects and these constants need to be made available to all projects, a
separate project containing either a module or class with shared members is
acceptable. Either technique should be easily understandable by other
developers.

-Sam Matzen
"One Handed Man ( OHM - Terry Burns )" <news.microsoft.com> wrote in message
news:OR***************@TK2MSFTNGP10.phx.gbl...

I didnt say you were confused, however, a lot of people seem to be.

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:uS*************@TK2MSFTNGP12.phx.gbl...

* "One Handed Man \( OHM - Terry Burns \)" <news.microsoft.com> scripsit:

Remember, a module is a 'Sealed' Class which in imported

automatically,

all members and properties are 'Shared'.

Personally, I avoid Modules and perfer to explicitly use Classes, this
avoids all the confusion surrounding Modules.

What confusions?!

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

[One Handed Man \( OHM - Terry Burns \)]

Thanks, but your stating whats already been said with the exception of
contradicting what I said about Modules being confusing for some people.

You will see this question come up with regularity for people who have come
from VB6 to .NET, they want to do things in the old way and are familiar
with Modules, but dont realise that they dont work the same way.

I can say this with some authority having been on this NG for nearly a year
now.

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

"Samuel L Matzen" <sm*****@slm.com> wrote in message
news:O%****************@TK2MSFTNGP12.phx.gbl...

There are a number of issues here:

1. There really isn't a good OO place to put what we used to call "header
files". From what I can tell the community has pretty much decided that
putting them in shared properties or fields of a class. This seems to work fine and from what I can see has no ill effects.

2. In general the VB.NET community is familiar with modules which as I
understand it are converted to classes with all of the members shared when
the IL is created. And, since modules are a "standard" part of VB I don't
see any reason they shouldn't be used.

IMHO putting "global" constants in either a module, or as shared members of a class is quite acceptable. For those solutions where there are multiple
projects and these constants need to be made available to all projects, a
separate project containing either a module or class with shared members is acceptable. Either technique should be easily understandable by other
developers.

-Sam Matzen
"One Handed Man ( OHM - Terry Burns )" <news.microsoft.com> wrote in message news:OR***************@TK2MSFTNGP10.phx.gbl...

I didnt say you were confused, however, a lot of people seem to be.

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:uS*************@TK2MSFTNGP12.phx.gbl...

* "One Handed Man \( OHM - Terry Burns \)" <news.microsoft.com> scripsit: > Remember, a module is a 'Sealed' Class which in imported

automatically,

all

> members and properties are 'Shared'.
>
> Personally, I avoid Modules and perfer to explicitly use Classes, this > avoids all the confusion surrounding Modules.

What confusions?!

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