[AccessD] Constants

James Button jamesbutton at blueyonder.co.uk
Sun Oct 3 10:19:31 CDT 2021

Also REMEMBER THERE ARE THE %environment% variables that you can see using a
command window and the (DOS) command SET
You can see the basic system folders that the logged-in user's current WINDOWS
session is assumed (by the OS and Office etc.) to be using.

>From those you can do a simplistic check that the environments and locations you
have stored for a particular users "Documents"  folder etc., and the OS
partition letter are as you have recorded from that users past sessions.


-----Original Message-----
From: AccessD
<accessd-bounces+jamesbutton=blueyonder.co.uk at databaseadvisors.com> On Behalf Of
Gustav Brock via AccessD
Sent: Sunday, October 3, 2021 3:19 PM
To: Access Developers discussion and problem solving
<accessd at databaseadvisors.com>
Cc: Gustav Brock <gustav at cactus.dk>
Subject: Re: [AccessD] Constants

Hi Arthur

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


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


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


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.


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_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...

AccessD mailing list
AccessD at databaseadvisors.com
Website: http://www.databaseadvisors.com

More information about the AccessD mailing list