proper place for a variable

  • Thread starter Thread starter Frank
  • Start date Start date
F

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
 
Frank said:
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
Click to expand...
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.
 
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
 
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 said:
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?
Click to expand...

I suggest a friend module that provides the variables and constants.
 
* "One Handed Man \( OHM - Terry Burns \) said:
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.
Click to expand...

What confusions?!
 
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
 
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
 
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.
 
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 ) said:
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 said:
* "One Handed Man \( OHM - Terry Burns \)" <news.microsoft.com> scripsit:
Click to expand...
automatically,
Click to expand...
 
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 said:
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
Click to expand...
 
Back
Top