[AccessD] Constants

[Arthur Fuller]

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> 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> på
> vegne af Arthur Fuller <fuller.artful at gmail.com>
> Sendt: 3. oktober 2021 15:39
> Til: Access Developers discussion and problem solving <
> 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
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>


-- 
Arthur