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

[Herfried K. Wagner [MVP]]

Ross,

"Ross Presser" <rp******@NOSPA Mgmail.com.inva lid> schrieb:

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?

That's what my concern is about. Classes are IMO a language feature used to
model entities, and thus not intended for /grouping/ objects (functions,
constants, ...) with a loose relationship.

However, I don't think that modules are the best possible solution because
they are automatically imported. I would prefer modules which need to be
imported explicitly or whose members do not always appear in IntelliSense.

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

[alantolan]

I was neccessarily talking about a class that contains only constants
(though that is not intrinically a problem), I was talking about
associating constants with an appropriate class rather than sticking
them in a general holding tank.

Simple example, Client Colors

Say we have an application and want to have all the forms use a given
color scheme (we want a specific one rather than use the Windows
scheme)

Instead of setting them on all the forms at design time (which will be
tedious to change when someone in marketing says, 'Oh! Puce is the new
black!"), we have a set of constants for the colors.
Where do we put them?

We can stick them in a module, or
We can place them in, say, a ClientConfig class along with the default
screen height and width and whatever other values that we reckon are
appropriate for Client Configuration.

Does it have any functionality included? Perhaps not, at first; we have
a fixed set of colors that the user is not allowed to change.

But if at some point we decide to allow the users to customize the
client colors we can add that functionality to this class and with very
little (if any) change to the application code we now have a client
with customizable colors.

I do not see that a module is 'sematically more correct' or even
semantically anything. A module started off life as ' the source code
for a program', evolved into 'a compilation unit' and now to me seems
like a vermiform source file. I personally think they are not useful
but that's a free opinion (and worth every penny)

My comments boil down to

1) A single large source file (be it class or module) for holding all
the constants that may need global scope, is a bad thing.

2) On anecdotal evidence, one a StdDef.bas gets created, everything
gets dumped in there. Almost by reflex. We're short on time, don't
have a chance to work through where a new 'something' should be put.
Stick it here and we'll get back to it later... promise.

3) Constants are given a global scope when they need to used in more
than one place but they can be usually said to 'belong' to a specific
piece of functionality and should be associated with that.

e.g.
ClientConfig.SC REEN_WIDTH
MyApplication.A PP_NAME

4) Sort of OT; Low level constants and declares should not be visble
to the application code at all.
P/invoke delcarations, OS constants (say, WS_EX_TOOLWINDO W or
SIZE_MINIMIZED) should be wrapped by a class and that functionality
invoked through the class.
This removes the need for them to be in the global namespace at all.

Alan.