I have an application protected by XLS Padlock, which has an issue with the Excel save functionality.
There are two scenarios with different behavior regarding the save functionality.
Scenario 1
- The user starts first the protected workbook/application, e.g. myexcelapp.exe
- The user starts second an unprotected workbook, e.g. Book1.xlsx
- The user wants to save the unprotected workbook, but the “Save As” is grayed out and he has only the possibility to save his non protected workbook as a XLSC “Secure Excel Files”-type.
Scenario 2
- The user starts first the unprotected workbook.
- The user starts second the protected workbook/application.
- The user can now save the unprotected workbook normally and the protected workbook is still protected by the wanted save as “Excel Secure Files” type.
What is the cause that the user has to start the workbooks in the correct order to keep maintaining the normal save functionality for the unprotected workbook(s)?
How can I force the wanted behavior: secure save for protected workbook and normal save for unprotected workbook?
The cause is that in scenario 1, the second unprotected workbook is opened in the secure Excel instance. It’s not the case in scenario 2 where you have two Excel instances: the normal one and the 2nd secure instance started by the EXE.
You have options in XLS Padlock to help you:
This will prevent an unprotected workbook to be opened in the secure instance.
Unfortunately, enabling the setting “Do not allow loading/saving other workbooks” gives me the following error when I open an unprotected workbook afterwards.
How can this be prevented?
You can’t. XLS Padlock is doing its job by preventing users from opening other workbooks in the secure instance. Unfortunately, we can’t customize the error message here. The solution is to open another Excel instance manually.
That is indeed unfortunate and a limitation of XLSPadlock. Because of this, we might have to abandon XLSPadlock and move to a VB.net solution, although that will be quite some work and besides this I am satisfied with XLSPadlock.
Are there any plans to improve this behavior somehow?
xlspadlock has vba coding which you use in a save sub which turns the secure save off.
I.e.save as a normal xlspadlock. It is more than just save as. It is under 9.8 of the manual.
Is it possible to extend XLSPadlock with the following behavior?
If a secured workbook is loaded (with XLSPadlock), force each new workbook (from Desktop, Windows Explorer, by Start Menu, etc) to start automatically a new Excel instance?
Sure, we’re trying to implement an option for that in the incoming version 2.6.
That sounds like a interesting attempt. Do you need a beta tester? I’m here to help. 
Thank you for your offer. When we have something ready, we’ll contact you 
We found a workaround for your problem.
Place this VBA code into your workbook:
Private Sub Workbook_Open()
Application.IgnoreRemoteRequests = True
End Sub
I have tried the workaround by adding the suggested VBA to my workbook. It resulted in Excel not able to open any workbook anymore, with or without the protected workbook running. On opening of an Excel workbook (by an Excel file) it gives the error message [There was a problem sending the command to the program].
Since I was unable to use Excel after this in a normal manner, I had to revert it by the following steps.
- Start Excel (not from a Excel workbook, but the application directly).
- File → Options → Advanced
- Uncheck [Ignore other applications that use Dynamic Data Exchange (DDE)]
Do you have any suggestions?
It’s because the code here should only be executed in the compiled workbook, not at design time
Unless you have this additional code:
Private Sub Workbook_Close()
Application.IgnoreRemoteRequests = False
End Sub
Anyway, please wait for the release of XLS Padlock 3. It’s coming in the following days.
Good to hear!
If XLSPadlock v3 is released, I will test it with a trial version.
If it solves the issue, I will extend/reenable our expired software support for XLSPadlock, since we are stuck at v2.4.
Please keep me in the loop.
A simple workaround is to use a macro to open a new workbook i.e Workbooks.Add and then use the macro to save it as a .xlsm file in same or set path with say the date in the string. Once it has been closed and then reopened it can be changed. I prefer it this way to avoid users forgetting the file name.
It might be frustrating but I cant wait for the next version.
The full code example is
Dim XLSPadlock As Object
Set XLSPadlock = Application.COMAddIns(“GXLSForm.GXLSFormula”).Object
Filepath = XLSPadlock.PLEvalVar(“EXEPath”)
If Dir(Filepath & “DATA EXPORT”, vbDirectory) = “” Then
MkDir Filepath & "DATA EXPORT"
End If
'Set file name of destination workbook
strFile = " Data " & " Exp " _
& Format(Now(), “dd mm yy hh mm”)
strFile = Filepath & “DATA EXPORT” & strFile
Workbooks.Add
Set XLSPadlock = Application.COMAddIns("GXLSForm.GXLSFormula").Object 'need to restate else next line may fail
XLSPadlock.SetOption Option:="1", Value:="1"
ActiveWorkbook.SaveAs Filename:=strFile, ReadOnlyRecommended:=False, CreateBackup:=False
XLSPadlock.SetOption Option:="1", Value:="0"
Do procedures then
ActiveWorkbook.Close SaveChanges:=True 
Is there any news on the expected release date of XLS Padlock 3, which hopefully contains a fix for this ‘Excel instance’ issue? I would like to communicate this to our customers, since they are waiting for a solution.
Thanks in advance.
I have tested XLSPadlock 3 and at first sight it seems to have solved this issue.
Great that it works for you too now!
