As programmers we all know the more complex a system becomes, the more likely the possibility for bugs or things not working properly. System move towards chaos.
Especially with something like excel where os and versions vary across clients.
In an ideal world (for me) xls padlock would be one simple feature and nothing more. Macros always run when the workbook opens, and the macros can not be accessed without a password.
From there every problem is solvable by me the developer.
No exe file, no saving complexities, no millions of features to toggle.
Just the excel, everyone knows and loves, but the macros can not be turned off.
Probably impossible, but putting it out there.
I may just need to stick to web apps for future applications.
We are developing a VBA compiler that will generate DLL files instead of EXE files. The compiled macros in these DLL files can then be invoked directly within standard VBA macros, replacing other macros. This is similar to the VBA compiler integrated into XLS Padlock.
Advantages:
No need to handle EXE files or deal with antivirus issues, no code signing certificate required.
VBA code can be protected in the same way as with XLS Padlock.
Licensing features are integrated into the DLL, so protected macros will only work for instance if the end user is licensed.
This will work for Excel add-ins, so you’ll be able to sell licenses for Excel addins.
Disavantages:
XLS Padlock offers more security features to protect your workbook.
For optimal protection, you must move some vital macros to the VBA compiler so that if someone removes the calls to the protected macros, your workbook should stop working. So, basically, this VBA compiler is only useful if your workbook uses VBA.
Just some food for thought for you guys:
Good developers can handle licensing and most of the other features.
I run an API call to a google sheets on file open, to dynamically validate opening the file. This is what i use over your built in licensing.
I think we can also handle the security.
So you want to copy my formulas and four-layer logic for a 160 sheet excel book?
Ok! Good luck! That will be fun…
And if you know how to automate that through code, you likely never hired me in the first place.
Want to hire a new developer? Have fun training him on the industry.
Updates and future roll-outs? Forget about it.
Sorry for the rant. What im trying to say is: THE REASON why i use xls padlock, is that excel opens every time with macros disabled. And that is the core issue.
You guys are genius and magically solve this problem with the .exe compile.
But in a dream world, a normal excel file a could check that the user has a valid license for the file and any of it’s downstream saves or copies. Everything else remains as is. This would satisfy 99% of client use cases for me.
This may not be the case for most of your customers, i don’t know, but for me, every other feature is a bug liability and adopting .exe files is a bit clunky and requires big client buy in.
Would a DLL solve this, I don’t see how?
I welcome any suggestions.
Thank you for your feedback.
Indeed, the DLL version won’t deal with activating macros automatically. But we have demand for that compiler. Moreover, it will work with Excel add-ins and even other Office products that offer VBA scripting.