search

twinbasic / twinbasic

261 stars 23 forks source link

Cross-project code execution - ala VBA #781

Open mburns08109 opened 2 years ago

mburns08109 commented 2 years ago

Is your feature request related to a problem? Please describe. In VBA, it is possible to execute code across document boundaries, or, in software development terms - across different project scopes. I don't yet see how this will be enabled or accommodated in tB.

Describe the solution you'd like In Excel VBA, you can have multiple separate "projects" loaded into the VBA environment simultaneously. In practical terms, this is simply having multiple workbooks open simultaneously. However, this has operational consequences. Because in the Excel VBA environment, all of: a Personal.xlsm workbook; a VBA Add-in (or multiple such COM and VBA Add-ins); and multiple simultaneously-open workbooks (each with differing worksheet compositions). ALL those projects code modules are open and available to one another simultaneously.

IN VB6 terms this is functionally the same as having MyProjectA.VBP and MyProjectB.VBP both loaded in the IDE simultaneously, and having a "super-scope" where MyProjectB could call upon and execute MyProjectA's functions/subs/classes(/forms/reports, etc.).

This means, in programming terms, that Project A's code is accessible to and executable from Project B's context(s). (Indeed, this very capacity is necessary for any VBA Addin code to function.)

Describe alternatives you've considered none as yet.

Additional context I think that describes the crux of the issue I'm trying to raise here. I'm asking if this has been at all considered as a part of envisioning a future where tB can be called upon as a replacement IDE for VBA. If not, then this capacity is going to be a required part of trying to fulfill that role properly. In other words - can tB be called upon in the manner like a VBA Add-In to Excel (as an architectural question)?

WaynePhillipsEA commented 2 years ago

Conceptually it's very similar to the packages support that we already have in tB. When tB loads a package, it actually loads it exactly the same as it loads an ordinary project, and then imports the public symbols into the root project. The main difference between packages and multi-project setups is that packages are locked (read-only), and this does simplify the handling somewhat since tB can just compile the package once when it loads it, and not have to worry about doing any live synchronization between multiple projects being edited.

Architecturally, I'd say we're probably 80% there already, in terms of supporting multi-projects.

mburns08109 commented 2 years ago

I'd perhaps add to the above, in that the composition of the package (to use your term), would also have to be able to automatically adjust (as does Excel VBA) for when additional workbooks are opened/closed in the "parent" application that "hosts" VBA - presuming that like Excel and Word, they support that concept - (Access does not do this, and Access VBA treats the VBA environment in a "single project only" manner).

That capability may be hampered in that Office apps do not presently expect to have to share any APIs that inform other IDE environments of changes to open documents in the (singleton?) hosting app. So, a workaround (file drag & drop-style?) method may be required.