[AccessD] Constants

Rocky Smolin rockysmolin2 at gmail.com
Sun Oct 3 15:43:43 CDT 2021


In a module declare as Public all the constants needed to define the
customer's environment. Then declare the same set of Public constants only
with your environment criteria.  During development comment out the lines
of his declares.  Before you deliver the app comment out your lines and
uncomment his. Quick and dirty but effective.

r
On Sun, Oct 3, 2021 at 9:22 AM Arthur Fuller <fuller.artful at gmail.com>
wrote:

> 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
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>


More information about the AccessD mailing list