Automatic Protection Workflow

The Automatic Protection Workflow is the heart of VBA Padlock. You open your existing Excel, Word, PowerPoint, or Access file (the one with the VBA you already wrote), and VBA Padlock does the heavy lifting: it reads your macros, works out which procedures can safely move into a compiled DLL, shows you the plan, and then produces a protected copy of your document. Your original file is never modified.

---

1. Open your macro-enabled Office file (Ctrl+O). The first time you open a file, VBA Padlock analyzes it automatically.
2. Review the analysis in the Protection Review: every module and procedure gets a verdict: moves to the DLL, or stays in VBA (and why).
3. Produce the protected file: VBA Padlock compiles your code into the DLL, generates the VBA wrappers and the bridge, and injects everything into a copy of your document.
4. Test Run (Ctrl+F5) opens the protected copy directly in Office so you can verify everything works.

That’s the whole loop. No manual script writing, no copy-pasting wrapper code, no bridge injection step; those are now handled by the conversion engine.

---

When you open a file (or click Re-analyze), VBA Padlock extracts your VBA modules directly from the Office file using a read-only COM session: macros stay disabled the whole time, and Access databases are copied first so the original is never touched.

Each procedure then goes through the compile gate: a per-procedure analysis that decides what can move into the DLL and what must stay in the document. The gate is conservative by design: anything that cannot safely run inside a DLL is kept in VBA, and the review tells you exactly why.

Code	Verdict	Why
Standard-module procedures	→ DLL	Compiled into the protected DLL; a delegating wrapper stays in the document.
Class modules	→ DLL	Compiled into the DLL and removed from the document.
Property Get/Let/Set in standard modules	→ DLL	Moved as a group; accessors are never split between host and DLL.
Event handlers (Worksheet_Change, Document_Open, …)	VBA	Office only fires events on code living in the host module.
UserForm modules	VBA (form)	Forms and their code-behind cannot run inside a DLL.
Document modules (ThisWorkbook, Sheet1, …)	VBA (document)	Document-module code stays in the Office file.
Procedures using shared module-level variables	VBA	Moving them would split state between host and DLL. The whole group stays together.
Procedures depending on a kept procedure	VBA	The dependency closure is demoted safely (depends on <proc>).

You can override individual decisions with the per-procedure checkboxes in the Protection Review, and if a forced move would create an unsafe host/DLL state split, VBA Padlock demotes the whole shared-state group rather than letting it break silently.

Many real-world macros use unqualified host globals: Range, ActiveSheet, ThisWorkbook, and friends. VBA Padlock automatically qualifies them (Application.Range, …) during conversion so that more of your procedures can move into the DLL. The transform is scope-guarded and string/comment-safe, and covers With headers too.

Symbolic constants like xlUp, wdFormatPDF, ppLayoutTitle, acExportDelim, or msoTrue compile straight into the DLL. Which constant libraries are available is driven by the References dialog; sensible defaults are pre-selected per host.

---

Clicking Produce Protected Office File runs a five-phase pipeline (validate, import, build DLL, inject, verify) with live progress and a working Cancel button. See the Produce reference for the phase-by-phase details.

Safety is built in at every step:

• Your original file is never written to. The wrappers and bridge are injected into a copy, saved next to your source as <name>_protected<ext>.
• A timestamped backup of the document is taken and verified with a SHA-256 checksum before any injection, with automatic rollback if anything goes wrong.
• A verification pass re-opens the produced file and checks the injected project before reporting success.

---

Protection is rarely a one-shot operation. The workflow is built for round trips:

• Editor markers: the Code Editor shows per-procedure gutter and line badges indicating what moves to the DLL and what stays in VBA; you see the split as you type.
• Re-analyze re-imports the VBA from your source file and refreshes the review at any time.
• Per-module Lock: lock a module against Re-analyze overwrites (padlock badge in the Project Explorer) when you’ve hand-tuned its stored source. On conflict you choose Keep, Keep + Lock, or Overwrite.
• Divergence guard: before any stored module is overwritten, VBA Padlock diffs the content and keeps a .bak backup of the replaced source.
• Syntax Check reports move/keep verdicts without building anything: a fast sanity pass from the Protect tab or the Edit Script tab.

---