Serious Excel and Access solutions get sold, copied and passed around, and VBA offers essentially no protection of its own — project passwords are a formality. A dongle changes the economics.
64-bit Office
Import the supplied .bas module, which declares the API with PtrSafe, and deploy the 64-bit library.
Dim serial As String
If KeyNubDeviceCount() = 0 Then
MsgBox "Please plug in your KeyNub license dongle."
Exit Sub
End If
If KeyNubOpen("") <> 0 Then Exit Sub
If Not KeyNubIsGenuine() Then Exit Sub
KeyNubSessionOpen
serial = KeyNubSerial()
KeyNubCloseCode language: VB.NET (vbnet)32-bit Office: use COM instead
This is the one thing worth reading carefully. The core library uses the cdecl calling convention; VBA’s Declare emits stdcall. In a 64-bit process there is only one calling convention, so the difference does not exist and the Declare module is correct. In a 32-bit process neither side cleans up the arguments and the stack pointer drifts with every call.
We have not been able to measure this on a 32-bit Office installation, so we state it as the risk it is rather than dismissing it. If you are on 32-bit Office, use the COM interface instead — it is the same object VB6 uses, it works from VBA unchanged, and the calling convention stops being your problem.
Set dongle = CreateObject("KeyNub.Dongle")Code language: VB.NET (vbnet)Gate on data, not a message box
A MsgBox and an Exit Sub are trivially deleted — anyone who can open the VBA editor can remove them. Encrypt the rate tables, pricing constants, formulas or thresholds the workbook actually needs, and decrypt them through the dongle at run time. Then a copied workbook opens perfectly and computes nothing.
