"Save As" not working for non-protected workbooks

ArthurBorsboom

ArthurBorsboom

New member
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.

XLSPadlock1.PNG788×455 25 KB

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?
 

Attachments

  • XLSPadlock1.PNG
    XLSPadlock1.PNG
    25 KB · Views: 0
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:

image.png760×462 41.6 KB

This will prevent an unprotected workbook to be opened in the secure instance.
 

Attachments

  • image.png
    image.png
    41.6 KB · Views: 0
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?
 
We found a workaround for your problem.
Place this VBA code into your workbook:
Code: 
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].

Error-message-open-workbook
Error-message-open-workbook397×131 5.92 KB

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)]
Undo-change
Undo-change840×685 30.7 KB

Do you have any suggestions?
 

Attachments

  • Error-message-open-workbook.PNG
    Error-message-open-workbook.PNG
    5.9 KB · Views: 0
  • Undo-change.PNG
    Undo-change.PNG
    30.7 KB · Views: 0
It’s because the code here should only be executed in the compiled workbook, not at design time
gdgsupport said:
rivate Sub Workbook_Open()
Application.IgnoreRemoteRequests = True
End Sub
Click to expand...
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
Code: 
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 😄
 
Last edited:
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.
 
You must log in or register to reply here.
Back
Top