How to make constants available for the whole application?

[Bill Nguyen]

I need to make a set of constants to be available for the whole application.
Public const is confined to the form from which constants are declared.
Is there a way to declare once and all forms can access the constant values?
Thanks
Bill

[Al Reid]

"Bill Nguyen" <bi************ *****@jaco.com> wrote in message news:u$******** *****@TK2MSFTNG P12.phx.gbl...

I need to make a set of constants to be available for the whole application.
Public const is confined to the form from which constants are declared.
Is there a way to declare once and all forms can access the constant values?
Thanks
Bill

Place them in a standard module.

[Herfried K. Wagner [MVP]]

"Bill Nguyen" <bi************ *****@jaco.com> schrieb:

I need to make a set of constants to be available for the whole
application.
Public const is confined to the form from which constants are declared.
Is there a way to declare once and all forms can access the constant
values?

If you place them in a class, you will have to qualify the constant's names
with the name of the class containing the constant definitions (e.g.
'Form1.Constant 1'). Alternatively you can place the constants in a module
in order to be able to access them without explicit qualification.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[alantolan]

By declaring a public constant in a class you can make it visible
anywhere that class is visible, it just needs to be accessed using the
class name

e.g.

public class Widget
public const MAX_SIZE as integer = 17
end class
... < some other code >

if (size < Widget.MAX_SIZE ) then
DoSomething
end if
Also, declaring them in a module will make them visible anywhere that
module is visible.

e.g.

public module StdDefs
public const MAX_SIZE as integer = 17
end module

if (size < MAX_SIZE) then
DoSomething
end if

I really dislike the module approach. Some of that is just my Java
background whispering, "Modules, we doan need no stinkin' modules. Just
use classes", but I also dislike the idea of stuffing all the various
constants that one needs for an application into a single std defs
module.

How many constants REALLY need to be accessed everywhere and even those
which do, why are they not associated with classes.

So far I have it possible to always associate constants with
appropriate classes.
Prepending the class name may mean extra typing but so does using
variable names of more that 2 chars in length; the amount of typing
(within reason) should not be the only selection criterion and the
class name usually helps explain the context/use of the constant.

[Herfried K. Wagner [MVP]]

<al*******@user s.com> schrieb:

public module StdDefs
public const MAX_SIZE as integer = 17
end module

if (size < MAX_SIZE) then
DoSomething
end if
I really dislike the module approach. Some of that is just my Java
background whispering, "Modules, we doan need no stinkin' modules. Just
use classes", but I also dislike the idea of stuffing all the various
constants that one needs for an application into a single std defs
module.
Well, I dislike the use of interfaces for grouping constants which is often
used in Java because of the /lack of/ semantically more correct modules.
How many constants REALLY need to be accessed everywhere and even those
which do, why are they not associated with classes.

Imagine a bunch of p/invoke declares, type definitions, and constants. IMO
modules are a good solution for grouping these declares, ...

BTW: You can even fully qualify a constant defined in a module.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Bill Nguyen]

Thank you all.
It worked fine for me either way.

Bill
"Herfried K. Wagner [MVP]" <hi************ ***@gmx.at> wrote in message
news:e%******** ********@tk2msf tngp13.phx.gbl. ..

<al*******@user s.com> schrieb:

public module StdDefs
public const MAX_SIZE as integer = 17
end module

if (size < MAX_SIZE) then
DoSomething
end if
I really dislike the module approach. Some of that is just my Java
background whispering, "Modules, we doan need no stinkin' modules. Just
use classes", but I also dislike the idea of stuffing all the various
constants that one needs for an application into a single std defs
module.

Well, I dislike the use of interfaces for grouping constants which is
often used in Java because of the /lack of/ semantically more correct
modules.

How many constants REALLY need to be accessed everywhere and even those
which do, why are they not associated with classes.

Imagine a bunch of p/invoke declares, type definitions, and constants.
IMO modules are a good solution for grouping these declares, ...

BTW: You can even fully qualify a constant defined in a module.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[alantolan]

>Imagine a bunch of p/invoke declares, type definitions, and constants. IMO

modules are a good solution for grouping these declares, ...

The point was that such things as p/invoke declares constants, et al.
are generally not used randomly throughout the system, they provide
support for some specified functionality that functionality can be
grouped together within a class.

The usual problem with a general 'definitions and constants' module is
that it becomes a dumping ground for all items that "we don't know
where it should really go", or "we don't have time to sort out at the
moment".

If we don't have just one module and spend time splitting them up in
some useful fashion then why would one not put them into a class.

[Herfried K. Wagner [MVP]]

<al*******@user s.com> schrieb:

Imagine a bunch of p/invoke declares, type definitions, and constants.
IMO
modules are a good solution for grouping these declares, ...

The point was that such things as p/invoke declares constants, et al.
are generally not used randomly throughout the system, they provide
support for some specified functionality that functionality can be
grouped together within a class.

The usual problem with a general 'definitions and constants' module is
that it becomes a dumping ground for all items that "we don't know
where it should really go", or "we don't have time to sort out at the
moment".

I don't see any difference in creating a class or module to contain all the
stuff "dumping around". This problem is /not/ related to the existance and
use of modules.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[alantolan]

The OP was a question on how to make constants available to the whole
program; modules or classes can be used for either. I stated a
personal preference for the classes option to which you replied that
modules were 'sematically more correct'

I am still confused by that comment.

VB.Net is an OO language, it behooves one to use OO designs and not
just cut-and-paste VB6 code, tweaking it until it compiles.

Constants in Modules:
If an application is designed/implemented as a set of inter-relating
classes/objects then there should be no need for 'naked' constants in a
module.

P/Invoke Declares In Modules:
Why should the application code see/know about p/invoke declarations?
The functionality should be wrapped in a class and that class used,
reducing the 'surface area' that the application developer needs to
know/remember.

Classes as Dumping Grounds:
Although one can construct a class to act like a module and then use it
as a dumping ground for misc defs, why would one?

My point was that associating the constants with the appropriate class
is a better option than putting them into a general module, not that
one is incapable of using a class like a dumping ground. Better tools
do not prevent poor design, they just provide and opportunity to do
things better than 'the way we've always done it'

Alan.

[Ross Presser]

On 23 Jun 2005 08:55:45 -0700, al*******@users .com wrote:

My point was that associating the constants with the appropriate class
is a better option than putting them into a general module, not that
one is incapable of using a class like a dumping ground. Better tools
do not prevent poor design, they just provide and opportunity to do
things better than 'the way we've always done it'

I don't understand why you consider it a "better design" to create a class
that does nothing but group a bunch of constants together, even if they are
semantically related, if there is no more substance to the class.

One step further, I fail to see the joy in a class that has no member or
private variables, only shared methods and constants. If I'm calling the
exact same function every time, and it has no internal state of any kind,
and I always have to feed it a full set of arguments, why should it pretend
it's part of a class or an object?