4.0 RD-VBA Program Structure and Organization
Note
This section is incomplete at this time. Planned content:
- [RD-VBAL §4.0.1 Application Composition]
- [RD-VBAL §4.0.2 Execution Pipeline and Interpreter]
- [RD-VBAL §4.0.2.1 Call Stack]
- [RD-VBAL §4.0.2.2 Memory Management]
- [RD-VBAL §4.0.2.3 External Calls]
- [RD-VBAL §4.0.3 Application Teardown]
A RD-VBA Environment is organized into a number of workspace source files and host-defined projects.
In design mode, the host environment maintains a static execution context that is an execution context containing the symbols provided by or defined in:
- static symbols defined by the environment host itself;
- the workspace source code;
- all referenced libraries;
- any extension symbol providers;
- any additional unbound symbols defined by the host (e.g. via immediate commands).
👉 The static execution context retains the state of immediate commands until an End command resets the execution context back to its initial state.
✨ A new RD-VBA source project always minimally contains a single standard (procedural) module with a host-defined default name. It is host-defined whether that single module contains any directives, annotations, or a templated entry point, or whether there are other default/templated modules in a new source project.
A RD-VBA project without any modules is valid and still define a symbol for the project, but produces no output and the host cannot exit design mode to run or debug.
While RD-VBA is normally hosted in a standalone hosting environment that is self-sufficient, the environment host must ultimately be able to attach to an external process that hosts a MS-VBA VBA environment, and externally address the host memory space to enable automation through COM and .NET interoperability; the external addressing technically allows a VBVariantValue to wrap an externally-defined object reference.
Note
As far as Microsoft Office Automation is concerned, this attach to host process feature ultimately positions the RDCore platform in a similar technical spot as Microsoft VSTO did, automating COM from the sidelines rather than from within the host. The comparison stops here though: a fully-realized RDCore platform could technically run RD-VBA CI/CD pipelines and integrate Enterprise software development lifecycles.
4.1 VBIDE Synchronization
Note
This specification is incomplete at this time.
🎯 The RDCore platform tooling shall ultimately include a lightweight VBIDE add-in responsible for:
- Exporting a MS-VBA source project to a RD-VBA workspace folder;
- Importing a RD-VBA workspace folder into a MS-VBA source project;
- Launching a RD-VBA environment host attached to a specified host process ID.