Hacking VBA to support native scripting runtime with no COM dependencies

24 pointsposted a month ago
by n013
(github.com)

10 Comments

blargthorwars

a month ago

Friendly reminder for MS Access fiends:

It's ok to store code in tables and then pass it to VBA for evaluation via Eval, or to ASF via the engine.Compile

cyanydeez

a month ago

But what if i want to debug my code?

blargthorwars

a month ago

Great question! Programmatically copy your snippet to a module, then call it:

Public Sub AppendCode() Dim cm As Object Set cm = Application.VBE.VBProjects(1).VBComponents("GeneratedLogic").CodeModule

    cm.InsertLines cm.CountOfLines + 1, _
        "Public Sub NewProc()" & vbCrLf & _
        "    MsgBox ""Dynamically added""" & vbCrLf & _
        "End Sub"
End Sub

mschuster91

a month ago

I've written my fair share of evil shit in VBA.

But... what is effectively eval() just in VB? Yikes.

moron4hire

a month ago

For the people who would be using this, they would almost never even have other people's code, say nothing of whether it's untrusted.

n013

a month ago

Honestly, ASF is literally sandboxed. Objects cannot be injected in the runtime. Also, VBA Expressions is intentionally limited to receive and return VBA strings. So, the system is safe for execute code from (almost) anyone.

n013

a month ago

You can inspect the AST in order to debug your code. For syntax highlighting, use tools like Notepad++ (ASF shares most of the syntax with Javascript). Each piece of code is commented, no obscure machine code.

fibers

a month ago

This looks so useful.