I want to unprotect a workbook immediately upon opening it, if it is protected the last time it was closed. I place the following code at the very beginning of the Open event:
If ThisWorkbook.ProtectStructure = True Then
Call ThisWorkbook.Unprotect("openpassword")
End If
Similarly, I want to protect the workbook right before it is closed. So I place the following codes at the very end of the beforeClose event:
If ThisWorkbook.ProtectStructure = False Then
Call ThisWorkbook.Protect("openpassword",True, False)
End If
ThisWorkbook.Save
Neither of those two works! Meaning, if a workbook is already protected upon opening, none of the code in Open event is executed. Not even the unprotect call!
Similarly, in the beforeClose event, all codes before the protection part are executed, except the protection part and any codes following it. I have confirmed that by placing it in different places in the beforeClose event.
Anyone could help me with this?
Additional explanation why I want to do this: the workbook is being shared among users with different level of authorized access. Most users face a protected workbook when allowed to work on only certain sheets. Hence, depending on who uses it last, the workbook could be closed in a protected state or unprotected state. If it is unprotected during the usage, I need to protect it immediately upon closing, so that the next unauthorized users will open a protected workbook.
Can you check that the events are actually firing? Try putting a Stop at the beginning of each event handler to see they are called. If the code isn't executing, what happens if you save it as a trusted document?
Just a few things:
Why don't you force a protection when closing for everyone, and only allow unprotecting when opening for certain people?
How are you determining which users can unprotect the workbook?
You're not saving the workbook as a shared workbook, right? It's a normal workbook, but accessed by different users. Shared workbooks are a bit funny with protection.
Try the following instead:
Dim sht As Worksheet
For Each sht in ActiveWorkbook.worksheets
If sht.Protection = True Then
sht.Unprotect("openpassword")
End If
Next sht
And the same at the end:
Dim sht as Worksheet
For Each sht in ActiveWorkbook.Worksheets
If sht.Protection = False Then
sht.Protect ("openpassword", True, False)
End If
Next sht
In excel - as far as I know - it isn't possible to protect the whole workbook directly but instead you have to protect every sheet.
You can at least try it, if it works I'm happy too :)
CU Kath
Related
What is the best way of protecting a specific Excel workbook?
I have an inherited script that includes the following common lines at the end:
ActiveSheet.Protect "my-password"
ActiveWorkbook.Protect "my-password"
However, I've noticed that as the script can take a few minutes to run users often switch to a new unrelated workbook whilst it solves - whatever else they are working on. The password protection is then inherited by the unrelated workbook upon the completion of the macro - since whatever other Excel file the user is working within is now "Active" (presumably? this is my reading of the problem).
The above script is in a workbook that can be renamed to whatever the user chooses, and be saved in any number of directories. How can I ensure that only the original excel file is locked/unlocked by the Macro, when other workbooks are in use?
I am sure there are many ways to do this, but which is the most foolproof method?
NOTE: using office 365
Thanks Dean's answers in the comments:
Early in the code (and in Worksheet_Change if appropriate) enter the following to define your sheet as an object (named default_ws in my case):
Set default_ws = ActiveSheet
When you are ready to lock your sheet or workbook you can then use:
default_ws.Protect "password-here" 'protect your sheet
ThisWorkbook.Protect "password-here" 'protect your workbook
Also note:
You could also define your workbook as an object as follows if desired:
Set default_wb = ActiveWorkbook
While trying to remove external connections from my protected Workbook (which imports data from a csv file) with VBA, I run into Runtime error '5'. Strangely, it works if I unprotect the Workbook.
I found this thread: Protect Excel Worksheet For Read Only But Enable External Data Refresh, but the proposed solution of unprotecting the workbook while the scripts are running is out of the question.
Here is the code that I use to remove the external data connections:
Sub RemoveExternalDataConnections()
Dim i As Long
For i = ActiveWorkbook.Connections.Count To 1 Step -1
ActiveWorkbook.Connections.Item(i).Delete
Next
End Sub
All in one, I would like the external data connections be removed even if the workbook is protected.
For anyone else - it seems that unprotecting the workbook is the easiest way. Setting up a password on a document/VBA project is not particularly safe anyway and it will not block most tech savvy users from accessing it.
Scenario
I am using a macro whereby I use Application.Visible = False to hide the workbooks. Also I use Application.Visible = True to unhide the workbook. At certain situation, I use Windows(ThisWorkbook.Name).Visible = False and Windows(ThisWorkbook.Name).Visible = True to hide and unhide only the workbook which contains macro.
Problem
I noticed during these operations, some additional excel windows(without any workbook) appear other than the workbook. Please see the picture below. You can see a grey window behind with a name Excel. That is the window I am talking about
If I closed that window, the whole excel will close. Does anyone know why this extra window appearing and how to prevent it from appearing?
I am not sure if this will meet the needs of your specific situation. But, what if you kept Application.Visible = False at the beginning of your code and changed Application.Visible = True to
Application.Windows(ThisWorkbook.Name).Visible = True at the end. This worked for me.
Hiding Excel
With the following code
Sub AppVisibleTrue
Application.Visible = True
End Sub
Sub AppVisibleFalse
Application.Visible = False
End Sub
you are showing or 'hiding' the 'whole' excel application, so you have to 'unhide' it in the same code, otherwise you won't be able to use the open files after you hide it, e.g. open a new workbook, in VBE add a new module and paste the above code into the module. Now, stay in VBE!!! Run the 'False' Sub. You will notice Excel has 'vanished', but you can still find it in the Task Manager's processes. Now run the 'True' Sub. Excel has 'reappeared'.
The following process will make Excel 'vanish'. The only way to close it will be via the Task Manager. If you not too familiar with doing this, just take my word for it.
Close the VBE. Now run the 'False' Sub. Excel has 'vanished'.
To conclude, this is obviously an error in your code, so I would suggest if you want to show a window (worksheet) that isn't 'ThisWorkbook' and you're dancing from one to the other, you should declare a variable
Const strSheet as String = "Sheet2"
Dim oSheet as Worksheet
'...
Set oSheet = ActiveWorkbook.Worksheets(strSheet)
Now you do with oSheet whatever you want.
Try to lose Active, Select and similar methods in the code.
If you would provide the actual scenario with the codes, a better assessment of the problem could be done.
The additional Excel window(s) could be related to your Windows Explorer. If you are previewing a document (in this case an Excel document) then the application to view that document is running in the background.
In this case, forcing the application to be visible will also make the background "preview" windows visible.
Excel 2016 (or 365) does not seem to fire the Workbook_Open() sub reliably or more precisely, not at all!
The simple event sub
Private Sub Workbook_Open()
MsgBox "Work book is open"
End Sub
does not seem to work. However, if a workbook is already open and then the workbook containing the above Sub is then opened, it does run as expected.
I notice that unlike Excel 2010, 2016 (365) opens each workbook in its own window, not a workbook window in the Excel application window. Is this a bug in 2016 and is there a workaround?
I have produced a work around for my own applications and that is call the activation of a worksheet and call my initialization routines from there. But a bit "rough" and it would be good to have the Workbook_Open() sub working correctly.
It is a simple single Sub in the ThisWorkbook module. Macros are enabled. In Excel 2010 it works perfectly, as do two other macros in other workbooks for which I have written macros. It is just this one thing with Excel 2016. Given that the Workbook_Open() sub is the gateway to a workbook it seems a little strange that we have to go to a workaround to make it function.
Try encapsulating the call with a new instance of Excel. Example below:
Sub OpenInNewExcel()
Dim Background_Excel As Excel.Application
Dim pathName As String
Dim fileName As String
Let pathName = "Enter your path here" 'include "\" at the end
Let fileName = "Enter your file name here"
Background_Excel.Workbooks.Open fileName:=pathName & fileName
Background_Excel.Parent.Quit ' This is how you close the file completely using VBA otherwise the file will close and the Excel Shell will remain.
End Sub
Also make sure that enable macros is turned on in the Options-Trust Center.
You have to add the file/folder location of your workbook as a "Trusted Location".
You can see more info about that in Designate trusted locations for files in Office 2016.
I have same problem then I found solution after google it:
https://www.myonlinetraininghub.com/excel-forum/vba-macros/excel-2016-workbook_open-event-doesnt-trigger
Then I also use "Private Sub Workbook_Open()" and "Public Sub Auto_Open()" open in excel 2016 that work fine:
Private Sub Workbook_Open()
CustomStartUp
End Sub
Public Sub Auto_Open()
CustomStartUp
End Sub
Private Sub CustomStartUp()
MsgBox "Work book is open"
End Sub
I've had this problem (I'm using Microsoft 365), and I found this thread.
It happens for me sometimes when I have another workbook already open, then, on trying to open my macro-enabled workbook, before any sheet is displayed I get the Microsoft warning message about macros. Then, although I click its 'Enable' button, the Workbook opens, macros do get enabled, but Workbook_Open doesn't run.
I've never known the problem to occur if no other workbook is open. (Of course, the user might still get the yellow-backed messages at the top of the workbook, asking them to click the Enable Editing and/or Enable Macros buttons.)
Note that my Workbook_Open just calls another 'workbook-opening' sub in a module to do all the opening processing.
My solution: When my workbook-opening sub is called, it sets a global variable to True to indicate it has run.
I've made it obvious to the user that the problem has occurred, by means of a 'Welcome' sheet with all its cells locked, so the user can do nothing; at this point all other sheets are very hidden. The workbook-opening sub, when it runs, deactivates this sheet and makes it very hidden, so the user never normally sees it, and makes the other sheets visible. But if this screen remains, it instructs the user to select the other workbook, then select this one again. My Workbook_Activate code then runs, and because the global variable isn't True, it calls the workbook-opening sub. If this global variable is True, it does nothing.
To make this work, the Workbook_Close sub makes the other sheets very hidden and the Welcome sheet visible, ready for the next time the Workbook is opened.
Hey presto, the problem is solved.
The Welcome sheet actually has a dual purpose, in that if either of the yellow-backed warning messages are displayed, it will remain and force the user, with suitable instructions, to click Enable Editing and/or Enable macros. If the users aren't au fait with macro-enabled Excel, they will just ignore these and try to carry on regardless.
All this is much easier to implement than to explain. I hope it's clear.
And I hope this might be of help to someone.
I had this issue with one of my files as well. I managed to fix this issue by running Workbook_Open manually in the VBA editor once open and saving the file in another location. The file in the new location should have no issue with auto-running Workbook_Open. If this doesn't work, copy the original file to a new location before manually running & saving.
If the newly saved file does not run Workbook_Open, repair your version of Office.
I have a workbook ("CodeBook.xlsm") that runs code using a BeforeSave event. When a user has multiple workbooks open and chooses to quit excel via File/Exit, the user is prompted whether to save workbooks, and if yes to CodeBook.xlsm, then the BeforeSave code is run. The problem is, at that point the ActiveWorkbook may not be CodeBook.xlsm, unless that happens to be the workbook that the user was in when he/she selected Exit Excel. If the user quit excel from another workbook, the BeforeSave code is running but the activeworkbook is some random file of the user, so all the references to specific worksheets and ranges in the BeforeSave code do not work.
I have tried various ways using a Static declaration to retain the name of CodeBook and workbook().activate to activate it when the application is quitting, but when BeforeSave runs, it can't pick up the name CodeBook anywhere, short of hard-coding the name into the code.
Any suggestions? How to retain a variable name in memory when there is no code running, but is there when a user initiates a quit excel, OR how to activate a specific workbook when Excel is quitting from a user command and not from application.quit. Using excel 2010.
I overcame this by including a reference to the specific workbook.
For example, this code simply saves the date/time stamp in cell A1 of Sheet1 before closing the document. By adding ThisWorkbook, it works on the specific workbook that the code resides in. If you don't add ThisWorkbook then it will work on the active workbook when the user quits.
Private Sub Workbook_BeforeClose(Cancel As Boolean)
ThisWorkbook.Worksheets("Sheet1").Range("A1").Value = Now()
End Sub
Place this code in the ThisWorkbook module.