rockysmolin2 at gmail.com
Sun Oct 3 15:37:06 CDT 2021
Gather tem all in a module and declare each as Public.
On Sun, Oct 3, 2021 at 6:39 AM Arthur Fuller <fuller.artful at gmail.com>
> 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...
> AccessD mailing list
> AccessD at databaseadvisors.com
> Website: http://www.databaseadvisors.com
More information about the AccessD