By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,464 Members | 1,616 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,464 IT Pros & Developers. It's quick & easy.

Integer Resources

P: n/a
I want to have a resource file with integers, rather than strings, and
have VS 2008 generate a global object with integer properties, rather
than string properties. Is this possible?

(I know I can convert the values to strings, but I'd like to know if
there's a cleaner solution.)

Thanks

Jul 9 '08 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Greg,

Add a settings file instead. In that, you can specify the type of the
setting and it will generate the type-safe properties to access the
settings.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Greg Esres" <ge****@boundvortex.comwrote in message
news:91**********************************@b1g2000h sg.googlegroups.com...
>I want to have a resource file with integers, rather than strings, and
have VS 2008 generate a global object with integer properties, rather
than string properties. Is this possible?

(I know I can convert the values to strings, but I'd like to know if
there's a cleaner solution.)

Thanks

Jul 9 '08 #2

P: n/a
Nicholas wrote:

<<Add a settings file instead. *In that, you can specify the type of
the setting and it will generate the type-safe properties to access
the settings.>>

Interesting...I wasn't familiar with this feature. Do you feel this
is an appropriate way to define constants, such as data input field
lengths?

Thanks
Jul 9 '08 #3

P: n/a
Greg,

Well, if they are truly constants, then the value would never change and
you should be defining them in code with const.

For something like data input field lengths, I would think that there is
a better way to do this. I would think that the underlying data store would
have information on the field length which you can query, and not have to
replicate the data (a DB will expose this information, if it is XML, then
you should be able to get it from the schema).
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Greg Esres" <ge****@boundvortex.comwrote in message
news:f7**********************************@a70g2000 hsh.googlegroups.com...
Nicholas wrote:

<<Add a settings file instead. In that, you can specify the type of
the setting and it will generate the type-safe properties to access
the settings.>>

Interesting...I wasn't familiar with this feature. Do you feel this
is an appropriate way to define constants, such as data input field
lengths?

Thanks
Jul 9 '08 #4

P: n/a
Nicholas wrote:

<<Well, if they are truly constants, then the value would never change
and
you should be defining them in code with const.>>

Most things in life are constant in the short term, but variable in
the long term. :-)

<<For something like data input field lengths, I would think that
there is
a better way to do this. I would think that the underlying data store
would
have information on the field length which you can query>>

Yes, that can be done, but presents somewhat of an organizational
challenge for a large database. I don't have a paradigm in place for
that. Might be able to use reflection to somewhat automate it, but
I'll have to give it some thought.

Preferable to have the code AND database pull from the same data
dictionary.

Thanks

Jul 9 '08 #5

P: n/a
On Jul 10, 12:19*am, Greg Esres <ges...@boundvortex.comwrote:
Nicholas wrote:

<<Add a settings file instead. *In that, you can specify the type of
the setting and it will generate the type-safe properties to access
the settings.>>

Interesting...I wasn't familiar with this feature. *Do you feel this
is an appropriate way to define constants, such as data input field
lengths?
If they are not truly constants, but rather tweakable parameters,
then, yes, an application-wide settings file is the way to go.
Just keep in mind that user will sufficient privileges to edit
your .config will then be able to change them on his system...
Jul 10 '08 #6

P: n/a
Pavel wrote;
<<If they are not truly constants, but rather tweakable parameters,
then, >>

Field lengths are probably something that no user should be able to
modify. I'd rather have some way to periodically ensure there was a
match between the database and what the application thought the field
length were. I don't like the idea of the program checking on every
execution, but having to change the source code and recompile is a bit
inflexible. Resource files seem to be a good compromise, but the .Net
environment seems to support only strings.

Thanks
Jul 10 '08 #7

This discussion thread is closed

Replies have been disabled for this discussion.