I am writing an add-in for Excel 2003, using VBA.
I have an Auto_Open subroutine, which automatically runs some code (setting up menus, etc) whenever the add-in is Opened as a file.
What subroutine name (or other logic) do I need to use in order to have code that automatically runs when the add-in is "Enabled" through Excel's Add-in manager? (And, relatedly, when it is Disabled)
Auto_Open and Auto_Close will do what you want. Checking the addin in the Addins dialog opens it, and unchecking it closes it.
Check out the Workbook_AddinInstall Event.
From Excel's VB Help, this event:
Occurs when the workbook is installed as an add-in
Ex:
Private Sub Workbook_AddinInstall()
MsgBox "This workbook was installed as an addin."
End Sub
The Workbook_AddinUninstall Event fires when the workbook is uninstalled.
Related
I have an Add-In that I created to update other Add-Ins as I release new versions. The AddIn runs when it opens (when Excel starts), it searches for new versions of other installed AddIns, and then the AddIn closes. If I try to open it from the code editor it just repeats this process. Any ideas on how I can access it?
If you hold the Shift key while an Excel file is opening, it will prevent any Automatic macros (e.g. the Workbook_Open event) from running.
Alternatively: Before you open the file, go to the Immediate Window (Ctrl+G) in the VBA Editor (Alt+F11) and run the following code
Application.EnableEvents = False
Then, when you are finished, run this to reset everything:
Application.EnableEvents = True
You may want to look into binding GetKeyState, so that your Macro can check for the Shift key before it does anything and Stop if it is held down
I have inserted an ActiveX spreadsheet control into an Excel VBA form.
I have written a procedure in the ThisWorkbook.Workbook_Open() event and it will not execute upon opening the workbook when the ActiveX spreadsheet control exists on the form.
In effort to simplify the problem, I have:
Created a new workbook.
Added a blank form "UserForm1".
Added an ActiveX spreadsheet control to "UserForm1", "Spreadsheet1".
In ThisWorkbook, added the Private Workbook_Open() event:
The Workbook_Open event does not execute when the workbook is opened. When the spreadsheet control is deleted from the form, the workbook_open event executes normally.
Macros are enabled in both cases. Other macros execute successfully when manually called.
How do I get the workbook_open event to execute with an ActiveX control on a VBA form?
Private Sub Workbook_Open()
MsgBox "Workbook_Open event has executed."
End Sub
UPDATE: When security is set to "Disable all macros with notification" and file is opened for the first time in protected view, the Workbook_Open() event is fired. On subsequent opening of the file, the event is not fired.
In Excel 2013, Excel likes to remember Excel windows (not worksheets) that were open, and when the workbook is opened again, also open up those windows:
From user interface: With a new workbook, Ribbon Tab "View" and then "New Window". Now two windows are open. Edit at will. Save the WorkBook. Then when that workbook is opened again, both windows are opened.
I'd like to prevent this this programatically within VBA, as part of WorkBook_Open I suppose, so that just one window would open. How can I do that? I've tried closing all windows using WorkBook_Close, that didn't work.
Just loop through the Windows collection and close them until you only have one open:
Private Sub Workbook_Open()
Do While Me.Windows.Count > 1
Me.Windows(1).Close
Loop
End Sub
While coding for an automation tool using VBA for Excel, I came across this situation. I have coded the "Close" command button as well as the "X" on the top-right of the form window. Both codes are same and serving their purpose.
I would like to know, if I close the workbook using the ActiveWorkbook.Close method in both the sub-procedures, then how to view the same Excel sheet's VBA project?
I am using Microsoft Office 2010.
Below is my code for reference:
Private Sub UserForm_QueryClose(Cancel As Integer, CloseMode As Integer)
If CloseMode = vbFormControlMenu Then
MsgBox "Thanks for using! Tool will now close.", vbInformation + vbOKOnly
Unload Me
ActiveWorkbook.Close
End If
End Sub
Visual Basic for Applications lives in a host... application - here Microsoft Excel.
If you have 10 workbooks opened, the Visual Basic Editor (VBE) will have 10 VBA projects in your Project Explorer window (Ctrl+R); closing one, will remove its VBA project from the VBE - the VBA code is in that workbook you just closed!
There are two types of VBA projects: one is the macro-enabled workbook (.xlsm), the other is a Microsoft Excel add-in (.xlam). The former lives and dies with the workbook it's written in; the latter lives and dies with the application it's loaded in.
If you need code that can manage multiple workbooks, consider saving as (F12) an add-in; ActiveWorkbook.Close would close the active workbook, and then the add-in is still loaded... and you can still view its VBA source.
If you only mean to close a form, I suggest you don't implement the QueryClose handler, and let the form close by itself - and leave the workbook open!. If you mean to close another workbook, I strongly recommend you avoid ActiveWorkbook and use a Workbook object reference instead.
I have a COM Add-in, which I want to make inactive with VBA Code (or maybe with another Excel Add-in '.xla').
This is my company's internal COM Add-in.
Working of this COM Add-in: While closing a workbook, a form is generated. This form asks which type of workbook (like private, confidential).
This COM Add-in can be made inactive without VBA by the following method:
Excel>Options>Add-Ins
Click On 'Manage - COM Addins' and 'Go'.
Deselect that Add-IN from Add-in manager & Click 'Ok'.
However, after opening a new workbook the add-in starts working again.
The solution to this issue is to create VBA code (/Excel Add-in) with workbook_open event to disconnect the COM add-in:
Application.COMAddIns("AddinName").Connect = False
But getting below error:
This add-in is installed for all users on this computer and can only be connected or disconnected by an administrator.
If one can make this COM Add-in inactive manually then why is it not allowed with VBA code?