@ZEEq
Although I think its not particularly important in terms of overall security, I think I have a simpler solution that will work for you without going through what I described in post #14. I've tested it & it worked for me.
Make sure your app does not contain an autoexec macro.
Use a startup form with code in the Form_Load event to check for the presence of an autoexec macro (that has been imported by someone).
If it exists, delete it before it has a chance to run
Rich (BB code):
'check & delete autoexec macro if it exists
If DCount("*", "MSysObjects", "Name = 'Autoexec' AND Type = -32766") > 0 Then DoCmd.DeleteObject acMacro, "Autoexec"
This works because, contrary to popular belief, the startup form loads BEFORE the autoexec macro. See my article:
This article debunks several widely believed fallacies about the autoexec macro used at startup
www.isladogs.co.uk
If you already have your own autoexec macro that you want to keep, first make a copy and call it e.g. autoexex (or something non-obvious for obfuscation). Then modify the above code to first delete the existing (possibly imported) autoexec macro, then copy autoexex and rename as autoexec. That way you'll know the correct autoexec macro will run
Rich (BB code):
Private Sub Form_Load()
'check & delete autoexec macro if it exists (as it may have been imported overwring the original)
If DCount("*", "MSysObjects", "Name = 'Autoexec' AND Type = -32766") > 0 Then DoCmd.DeleteObject acMacro, "Autoexec"
'Now copy the autoexex macro and rename as Autoexec to ensure the correct macro always runs
DoCmd.CopyObject , "Autoexec", acMacro, "autoexex"
End Sub
A bit tortuous but it will work.
For info I'm adding this info to the article linked in post #3. I will upload a new version in the next day or so