-
Notifications
You must be signed in to change notification settings - Fork 45
Project Configurations in VBAToolKit
The spine of a VBAToolKit project is the _DEV Excel workbook and its vtkConfigurations
sheet.
This sheet lists all the configurations of a VBAToolKit project.
A configuration is nothing more than a certain combination of modules. It allows different deployments of the project, adapting to both the usage and the environment.
The vtkConfigurations
worksheet is layed out in such a way that :
-
a configuration corresponds to a column
-
a module corresponds to a row.
At the intersection between a configuration column and a module row, you can find the path of the source file of the module for this configuration.
This means that in distinct configurations, the same module can have disctinct source files, and therefore different code.
For example, the "Development" configuration of the project would integrate the unit testing modules, while the "Delivery" configuration would not.
In the vtkConfigurations
sheet, the "Delivery" configuration will have the unit testing modules disabled.
Let's imagine a project dealing with databases. This project will be used for 2 different clients, that use 2 different DataBase Management Systems.
In the project, the name of the module centralizing the interactions with the database is DatabaseInteractions
.
In the vtkConfigurations
sheet, the "DeliveryForClient1" configuration will have the DatabaseInteractions
line pointing to Source/ConfProd/Client1/DatabaseInteractions.bas
, while the "DeliveryForClient2" while have its one pointing to Source/ConfProd/Client2/DatabaseInteractions.bas
.
As explained in the previous section, to each deployment its configuration.
For a certain deployment, VBAToolKit will create an Excel workbook from the source files listed in the chosen configuration.
It is impossible for the VBA IDE to have 2 modules with the same name at the same time.
For this reason, different versions of the same module cannot cohabitate in the same Workbook if they have the same module name.
This kind of problem can be avoided if gives different names to different versions of a module.
For example, instead of having Source/ConfProd/Client1/DatabaseInteractions.bas
and Source/ConfProd/Client2/DatabaseInteractions.bas
, one could have Source/ConfProd/DatabaseInteractionsClient1.bas
and Source/ConfProd/DatabaseInteractionsClient2.bas