I keep running into an issue where the worksheet in question gets updated, and then doesn't reflect the changes until I close and re-open the book. It's not really a big deal, I just want to simplify it a bit into a single button click.
I was told that this is impossible to do because closing a workbook will immediately stop execution of code, so you can't reopen the book. But since, I have learned about the PERSONAL.xlsb, and figured since it's a persistent workbook, it could handle the code execution to save, close, and reopen the workbook.
Basically, here's what I've got in the main worksheet:
Public Sub Refresh()
ActiveWorkbook.Save
Application.Run "PERSONAL.xlsb!Module1.RefreshCurrentSheet",ThisWorkbook.Name,_
ThisWorkbook.FullName
End Sub
Which then calls the personal.xlsb macro "Refreshcurrentsheet":
Private Sub RefreshCurrentSheet(ByVal sheetname, Optional ByVal sheetfullname = 0)
Workbooks(sheetname).Close
MsgBox "So far so good!" 'I never see this box
Workbooks(sheetfullname).Open
MsgBox "No errors here..." 'I never see this box
End Sub
This successfully closes the workbook in question, but code execution stops and it doesn't reopen. Is there a way around this? Some way to run the second macro in the persistent sheet without code execution stopping?
We can reopen the workbook using this code inside it (there is no need to use other workbook):
Sub test()
Application.DisplayAlerts = False
Workbooks.Open ThisWorkbook.FullName
Application.DisplayAlerts = True
End Sub
Related
Long ago I had a macro that would open some workbooks, do some fiddling, then close - all fully automated, called from the commandline so I could batch file it and stick it in windows schedule to run when needed.
I've had call to do it again and of course no longer have access to those files (like four companies ago) so had a bash at recreating them, but stuck on closing excel.
ActiveWorkbook.Close SaveChanges:=True
This works to close the workbooks I'm updating, however, if I use it on the macro containing workbook, it closes the workbook within Excel, but leaves the instance of excel running (with no workbooks).
Application.Quit
This is what I think should be the right command, however this also throws an error:
Run-time error '1004':
Application-defined or object-defined error
However, it's odd. If I just run that command within excel on its own, there's no error, it only errors if the workbook calls the macro containing it.
As it's an auto-launching macro, I have an initial macro in ThisWorkbook that has the Private Sub Workbook_Open() which kicks everything off.
I'd read that Application.Quit can cause this error message when the workbook has an auto-launching macro and it's called from a module, rather than ThisWorkbook, so I moved the Sub QuitExcel() that I created, containing just Application.Quit but still get this error.
The suggested posts from SO when posting this gave a few things to try, like DisplayAlerts=False and saving the workbook, so I updated my quit sub to:
Sub QuitExcel()
Application.DisplayAlerts = False
Application.EnableEvents = False
ThisWorkbook.Save
Application.Quit
ThisWorkbook.Saved = True
End Sub
(and various permutations of that)
However I still persist in getting the same error.
Interestingly, if I click "debug" (rather than end, continue is greyed out) Excel still quits, and doesn't actually go to debugging.
Anyone have experience in what I'm trying to achieve, I just want to kill Excel after it's finished running, from auto-launching a macro?
Answer turned out to be relatively easy, I need to close my workbook before quitting excel and the closing macro can't be in the ThisWorkbook, it has to be in a module (otherwise when the workbook is closed, access to the rest of the code is gone).
So my command ended up being:
Sub QuitExcel()
ActiveWorkbook.Close SaveChanges:=False
Application.Quit
End Sub
Just needed a bit more googling and trial/error.
You should know that VBA code only run in a workbook context ThisWorkBook , that mean when you close it using WorkBook.Close, there will be no code to execute.
So, you only save then use Application.Quit
Do not close the workbook
For Each w In Application.Workbooks w.Save Next w Application.Quit
Strange issue when closing a workbook twice from VBA (Workbook_BeforeClose)
Hi. This problem appears to me in an extremely simple workbook: Workbook_BeforeClose only.
Option Explicit
Private Sub Workbook_BeforeClose(Cancel As Boolean)
ThisWorkbook.Close SaveChanges:=False
End Sub
If I open and close the workbook twice, the main Excel screen looks like this, and it's impossible to do something, I can only close it from the status bar:
If all you are trying to do is to not prompt the user to save changes, just play with the appropriate flags to 'trick' Excel that changes have already been saved.
Private Sub Workbook_BeforeClose(Cancel As Boolean)
Me.Saved = True
End Sub
This will allow the workbook to close, without prompting any changes to be saved, but this does not actually save them.
Notice the subtle difference between the words: Me.Saved and Me.Save.
Saved is a property that gets flipped to False when Excel detects changes were made as of the last save.
Save is a method - not a property as above - that actually will save the workbook.
Your workbook is already closing, which is what fired this event to begin with. No need to try to close it again within this event. Just tell Excel that no changes have been made since the last save, and it should close all on it's own - without the prompts.
It's possible you're re-triggering the event. Try something like this:
Private Sub Workbook_BeforeClose(Cancel As Boolean)
Static InProgress As Boolean
If InProgress Then Exit Sub
InProgress = True
ThisWorkbook.Close SaveChanges:=False
End Sub
I have a program that runs as soon as the workbook is open using the Private Sub Workbook_Open() function located in the ThisWorkbook object. I would like to add a closing function as well, so that basically the program will run as soon as the workbook is open, and then close right away so it never stays open, just runs and closes.
I've tried adding:
Workbooks("Fire Ext. Comments EXE.xlsm").Close SaveChanges:=False
...right before the End Sub at the bottom of the program, but the workbook stays open so I'm wondering if it belongs in a different module and then called separately? Let me know what you think.
you can try this, so that the application itself will close
Application.DisplayAlerts = False
Application.Quit
I have a sheet with a Workbook_Open code loading a userform.
After closing the form and the workbook Excel prompts me for the VBA Project password.
I've found some info on this issue on this pages:
http://support.microsoft.com/kb/280454
http://social.msdn.microsoft.com/Forums/office/en-US/8cb79e54-26ae-487c-8945-69b84b2e4eeb/com-addins-and-vba-password-prompt-bug
But it seems to be a problems with COM add-ins, which I have some.
The problem is that the add-ins are not mine and I can't change or disable them.
Is there any other solution?
For me, the problem was not some add-ins or unreleased references. It was the Dropbox Badge. As soon as I removed it, the password was not solicited anymore when I closed Excel. To disable Dropbox Badge, open the Dropbox app, go to Settings, then Preferences and in the General Tab select "Never show" under Dropbox Badge.
I found this solution on the following forum:
https://www.excelforum.com/excel-programming-vba-macros/1100960-ever-annoying-vba-password-prompt-at-close-of-excel-2.html
This happens when you have hanging pointers to objects.
For every 'Set xyz=' you do in VBA, make sure that you have a corresponding 'Set xyz=Nothing'.
Similarly for anything pointing to or obtained from COM objects.
Make sure you close any ADO connections etc.
Be especially careful to handle all errors so that ALL object variables are set to Nothing before the workbook can close, something along these lines:
Option Explicit
Option Compare Text
Public Sub Refresh()
On Error GoTo FAIL
Set wb = ThisWorkbook
wb.Activate
' do something useful
DONE:
On Error GoTo 0
Set wb = Nothing
Exit Sub
FAIL:
MsgBox Err.Description
GoTo DONE
End Sub
I have a number of workbooks that were experiencing the same problem with some users. We went through the process of checking for COM add-ins and various combinations of Windows and Office.
In the end we included the following code as part of the workbook_beforeclose event and the problem was resolved for our users.
Private Sub Workbook_BeforeClose(Cancel As Boolean)
Dim intResponse as Integer
'If the workbook needs to be saved then ask the user if they want to save the workbook, if not then exit without saving
'Need a global boolean to ensure the request to save the workbook is not shown twice
If Not ThisWorkbook.Saved And Not blnStartedClose Then
blnStartedClose = True
intResponse = MsgBox("Do you want to Save the this Workbook" & vbNewLine & vbNewLine & _
"Select 'Yes' to save the workbook" & vbNewLine & _
"Select 'No' to close without saving", vbYesNo, "Confirm - Workbook Save?")
If intResponse = vbYes Then ThisWorkbook.Save
End If
'If the user has clicked on 'No' to save the workbook then reset the "Saved" property to TRUE so that when we exit this routine no attempt to save the workbook is made
ThisWorkbook.Saved = True
End Sub
I've had some clients have this issue and I finally started getting it after installing BlueBeam Extreme. I unchecked the BluebeamOfficeAddIn in the COM Add-Ins and the password box stopped popping up when closing my .xlsm file. I'm going to do more digging to see if it's my code but I haven't had this issue until now and disabling that addin seemed to help...
I have a VBA macro which is called from a spreadsheet function (user defined function, UDF). When the spreadsheet is downloaded from the internet and the user has set "Trust Center" settings accordingly, the spreadsheet will open in so the called "Protected View". The function will not be called. A button "Enable Editing" is shown.
If the button is pressed, the spreadsheet is "trusted" and reopened normally, starting calculation, and hence calling the user defined function.
However, in that VBA function the value of Application.ActiveWorkbook is Nothing. This can be verified in the debugger.
Since I just need to read some properties (like path name) of the spreadsheet, I could alternatively inspect the availability of Application.ActiveProtectedViewWindow which should reference to the protected version of the workbook. In the debugger, this object can be inspected. However, running in release (without debug) the value of Application.ActiveProtectedViewWindow is also Nothing.
Both behaviors - especially the first one - appears to be a bug present in Excel 2010 and 2013 (see also a post at the MSDN forum ).
Question: Is there a way to get hold of properties of the active workbook after it has been enabled for editing?
PS: As a follow up to the nice observation of Siddharth Rout, that "ThisWorkbook" might work: In my case, the macro is not part of the Workbook being openend. The UDF is defined in an XLA. Hence, ThisWorkbook would reference the XLA. I do need to get the ActiveWorkbook (= the workbook calling the UDF) instead of ThisWorkbook (= the workbook running the UDF).
IMPORTANT REQUIREMENT:
My function is called as a user defined function, i.e., execution order is determined by Excel updating the cell.
The function is not part of the workbook being opened. It is part of an XLA.
I cannot add any code to the workbook which is opened.
Summary: The problem can be replicated and there are some possible workarounds. The most promising one - resulting from a chat - is to use ActiveWindow.Parent instead of ActiveWorkbook.
I was able to replicate the problem.
I tried
Private Sub Workbook_Open()
MsgBox "Application.ActiveWorkbook Is Nothing = " & _
CStr(Application.ActiveWorkbook Is Nothing)
End Sub
And I got True
However, then I tried this and it gave me False
Private Sub Workbook_Open()
MsgBox "Application.ActiveWorkbook Is Nothing = " & _
CStr(Application.ThisWorkbook Is Nothing)
End Sub
Now answering your question...
Question: Is there a way to get hold of properties of the workbook after it has been enabled for editing?
Yes. Use ThisWorkbook instead of ActiveWorkbook
Followup From Comments
Once the workbook completely loads after you exit the Protected Mode, you would be able to access the ActiveWorkbook object. To test this, put this code in the protected file.
Private Sub Workbook_Activate()
MsgBox "Application.ActiveWorkbook Is Nothing = " & _
CStr(Application.ActiveWorkbook Is Nothing)
End Sub
You will notice that you get a False
So once your workbook loads, your add-in can use ActiveWorkbook to interact with the opened file.
Here is another test
Private Sub Workbook_Activate()
MsgBox ActiveWorkbook.Path
End Sub
This is what I got the moment, I exit the Protected Mode
FOLLOWUP FROM CHAT
Using ActiveWindow.Parent.Path instead of ActiveWorkbook.Path would solve the problem.
I had this same issue today, and neither the accepted answer nor any other answer that I could find on this page or through searching the Google-verse worked for me. I'm using the version of Excel within Office 365, and I figured that was at the root of the problem.
I eventually came to a solution after finding a Microsoft Excel 2010 resource and hitting the old try-fail cycle for a few hours. Here's what I got:
Option Explicit
Public WithEvents oApp As Application
Private bDeferredOpen As Boolean
Private Sub Workbook_Open()
Set oApp = Application
End Sub
Private Sub oApp_WorkbookActivate(ByVal Wb As Workbook)
If bDeferredOpen Then
bDeferredOpen = False
Call WorkbookOpenHandler(Wb)
End If
End Sub
Private Sub oApp_WorkbookOpen(ByVal Wb As Workbook)
Dim oProtectedViewWindow As ProtectedViewWindow
On Error Resume Next
'The below line will throw an error (Subscript out of range) if the workbook is not opened in protected view.
Set oProtectedViewWindow = oApp.ProtectedViewWindows.Item(Wb.Name)
On Error GoTo 0
'Reset error handling
If oProtectedViewWindow Is Nothing Then
bDeferredOpen = False
Call WorkbookOpenHandler(Wb)
Else
'Delay open actions till the workbook gets activated.
bDeferredOpen = True
End If
End Sub
Private Sub WorkbookOpenHandler(ByVal Wb As Workbook)
'The actual workbook open event handler code goes here...
End Sub
The difference between the 2010 solution and mine is that I had to call Workbook_Open and explicitly set the oApp variable there, because without that assignment neither the oApp_WorkbookActivate nor oApp_WorkbookOpen functions would fire when I opened the file.
Figured that someone else might be able to benefit from this, so I posted it, despite the fact that the most recent update to this thread is better than 2 years old.
Best.
Try using Application.Caller.Parent.Parent instead of Application.Activeworkbook
This is not a complete answer to the original question, but a (dirty) workaround for a problem related to this.
I needed ActiveWorkbook to infer the workbooks path, that is ActiveWorkbook.Path.
An alternative to using ActiveWorkbook.Path is to check for Application.RecentFiles(1).Path which is the path of the most recently opened file. In many cases this will be the workbook for which the user just has "Enabled Editing". However, of course, this method may fail: In the case the used opened another sheet, then enabling the previously opened sheet.
(Note: ActiveWorkbook.Path give the path of the folder, while Application.RecentFiles(1).Path gives the complete path of the file, so there has to be some post-processing).
I know it's old thread, but i came across the same issue and i found solution ;)
The only way to go around it, is to use variable type Workbook
Dim wbk as Workbook
Set wbk = Application.ProtectedViewWindows(index).Workbook
Warning:
ActiveSheet returns Nothing when active window is protected too.
Dim wsh As Worksheet
Set wsh = wbk.Worksheets(index)
Try this code it works.
If (UCase(ActiveWorkbook.Name) = ucase("<YOUR XLA NAME WITH EXTENSION>")) Then
End
End If
Set wbObj = ActiveWorkbook
First time when you run the macro, it just ends without doing anything. Second time it picks up the proper file.