The main idea behind modular scripting to break up repeatable business functions or repeatable actions into the separate pieces which can be grouped together to run in compatible sets, but yet independently created and maintained. Modules and shared modules, which are VBA assets used in TestPartner that contain a declaration followed by a procedure, can be used effectively in modular testing.
The difference between these two is simply in how they are implemented.
A module is available only to test scripts in its own project and must be explicitly included in a test script for it to be referenced or called. If a module is created in the Common Project then it can be explicitly included in any test script.
A shared module is implicitly included in all test scripts contained inside its own project. If it is created in the Common Project it, is implicitly included in all test scripts.
If creating shared modules in a Common Project, be aware that any name or word used in the shared module should not be used in a test script or function. This could cause compile errors that at first sight may not make sense. Also, large numbers of shared modules in either the Common Project or another project add potentially unnecessary overhead to the test scripts being played back. This may create the potential for memory overrun issues.
Shared modules are best used as containers for a defined set of actions that are vital to testing, but should be available for every visual test or test script. The best examples of this are error handling or statistic gathering.