We have a number of XLA files being used to regularly update a XLSM workbook. Can both the XLA and XLSM files be encrypted? If so, during the process of updating XLSM workbook with a newer XLA file (using normal VBA procedures), can it be done with both files being encrypted, or do we need to decrypt both files before running this update?
Any clarification will be greatly appreciated! 
If you add the XLA files as companion files (a feature of XLS Padlock is called companion files), they will be stored in the EXE file and can’t be updated. In your case, it would be better to keep the XLA files outside the EXE since they are going to be updated. You can place the XLA files in the same folder as the output EXE file, and use our VBA code snippets (see our user guide shipped with XLS Padlock) to get the path to the folder where the EXE and XLA files will be at runtime.
Thank you for the explanation! The XLA files we use serve the role of fixes to the XLSM workbook. Our current XLSM workbook has a centralized design and is protected before distributed to the users. So there are dozens of different XLSM files out there. When we add new features or apply fixes to the XLSM, the user will click a button that pulls the updates from XLA files into his/her own copies of the XLSM.
We would like to know if we can protect our files described above using XLSPadlock. Once XLS Padlock turns the XLSM into an EXE file, can this EXE file still be changed (in terms of the underlying VB procedures)? Will we able to “unpack” this same EXE file to do the same kind of XLA-to-XLSM design change, or can we only construct new EXEs using XLSPadlock?
Thanks again!
The EXE will always remain the same, but if you let them, end users may save modifications as new encrypted workbooks called secure saves (in XLS Padlock terminology). When the EXE is started, end users are prompted whether they want to load a secure save and find their modifications, or use the original unmodified workbook.