[AccessD] Constants

[Gustav Brock]

Hi Arthur

Well, constants are not to change, so if you need to change them, use normal variables.

You could read during them launch from a table where one record only is marked as "active". Have two records, one for the client, one for you.

Or have a small config file the application reads at launch - could be a simple text file, you read, or a csv-file you link.

/gustav

________________________________
Fra: Arthur Fuller <fuller.artful at gmail.com>
Sendt: 3. oktober 2021 18:22
Til: Access Developers discussion and problem solving <accessd at databaseadvisors.com>
Cc: Gustav Brock <gustav at cactus.dk>
Emne: Re: [AccessD] Constants

Thanks, Gustav.

In your examples, I can certainly see the logic and the locations designated.  But in my case, I need to define paths as constants. The client's layout differs significantly from my own, in terms of where various files and folders reside. The best I have come up with so far is to define a set of constants for my environment and then to use a compiler directive to choose which set of constants to use; this enables me to develop one way and deliver another way. Is there a smarter approach?


On Sun, Oct 3, 2021 at 10:19 AM Gustav Brock via AccessD <accessd at databaseadvisors.com<mailto:accessd at databaseadvisors.com>> wrote:
Hi Arthur

I would say, that their scope determines it.
For example, for my date/time modules at:

    https://github.com/GustavBrock/VBA.Date

the constants used "all over" are held in one module, DateBase:

    https://github.com/GustavBrock/VBA.Date/blob/master/DateBase.bas

However, constants for callback functions are held in their module, DateCall:

    https://github.com/GustavBrock/VBA.Date/blob/master/DateCall.bas

and constants for use in one function only are located in these functions, for example as seen in function CallIntervals.

In any case, do document them, ie:

    ' Interval with minimum one microsecond resolution.
    Public Const MaxMicrosecondDateValue    As Date = #5/18/1927#
    Public Const MinMicrosecondDateValue    As Date = #8/13/1872#

This works well for me.

/gustav

Fra: AccessD <accessd-bounces+gustav=cactus.dk at databaseadvisors.com<mailto:cactus.dk at databaseadvisors.com>> på vegne af Arthur Fuller <fuller.artful at gmail.com<mailto:fuller.artful at gmail.com>>
Sendt: 3. oktober 2021 15:39
Til: Access Developers discussion and problem solving <accessd at databaseadvisors.com<mailto:accessd at databaseadvisors.com>>
Emne: [AccessD] Constants

The general question is where should constants be located? The reason I ask
is that my development environment  differs from the client's --
particularly in the location of files and app-location.
I inherited this app; I wrote parts of it but was not its principal
developer. He has since retired; hence the inheritance.
The app has a couple of dozen Constant declarations throughout. Frankly, I
hate this layout. My thought is to create a module containing "the truth,
the whole truth, and nothing but the truth," as it were. My notion is that
I can adjust everything by editing a single module, and even better, can
set a compiler constant (1 0r 0m or more should the occasion arise) to use
this or that set of constants, depending on whether I'm in development mode
or shipping mode.

In case this is not clear, here's an example:
My environment:
Const CON_APP_PATH = C:\XYZ
Const CON_XL_EXPORT_PATH = C:\XYZ\XLS
Const CON_TEMPLATE_PATH = "Documents\Custom Office Templates"

The "Documents" reference in the last constant actually refers to a
physical directory under Users, in case being C:\Users\Arthur\Documents,
and in the client's case it's C:\Users\David\Documents.

1. Will the reference to "Documents" survive on its own, or must I
explicitly identify each location, grouping the definitions within a
compiler directive?
2. Is it a good design pattern to locate all the constants in a single
module? The inherited app declares them within each particular module that
needs them, which IMO makes it really difficult to track them all. rick
Fisher's Find and Replace helps a lot, but still...

--
Arthur