I want to automate a process in excel with vbscript which is using third party COM ADD-IN
Sub LoadAddIn()
Dim oComAddIn As COMAddIn
Set oComAddIn = Application.COMAddIns.Item("C:\Program Files (x86)\Thomson Reuters\Eikon\EikonOfficeShim.dll")
oComAddIn.Connect = True
CreateFolder
End Sub
But while running excel from vbscript, it is opening without any add-ins enabled and formula which is using the above add-in are not working.
I googled so many websites but not getting exact syntax to use to connect third party add-in while executing excel from vbscript.
I can open the EIKON AddIn and start the process using the following:
'Start EIKON Update
Dim RetVal As Long
RetVal = ExecCmd("C:\Program Files (x86)\Thomson Reuters\Eikon\eikon.exe -officeexcel -a " & sPath)
Note that sPath is the full string path of the file I am opening.
Caveat: The file does not automatically close. I'm still working on that part.
Related
I have search on this site and beyond for an answer to these questions, and also trawled through a collection of VB/C# books I have on VB/VSTO. So far I've drawn a blank. I've posted the same question on a VB.NET facebook group, and if I get a solution, I'll post it here so it'll help others.
I am developing an application-level Add-In for Excel using VB.Net & VSTO.
Part of the functionality involves opening .xlsm (Excel macro-enabled) files.
I have three questions I hope you can help me with.
I want to open each xlsm file with macros enabled, but not launch
any Auto_Open macro in the xlsm file, or trigger the Workbook_Open
event. Is that possible?
The xlsm file may have it's own ribbon attached to the file. Is it
possible to inhibit the xlsm's ribbon from being added?
The xlsm file may have ActiveX controls that are connected to VBA
macros. If a VBA macro produces an error, is it possible to catch
the error in the .NET Add-In? The error may include "macro not
found"
For info, at present I disable macros using the code snippet below. Whilst that helps with item #1, it doesn't help with items #2 or #3 (in fact, disabling macros is the cause of item #3).
Currently when I open the xlsm file(s) I disable macros using the following code:
' WorkbookType is a string representing a keyword within the Excel filename
' xlApp is running instance of Excel
Dim xlApp = Marshal.GetActiveObject("Excel.Application")
aWorkbook = xlApp.ActiveWorkbook
aSheet = xlApp.ActiveSheet
' Save current macro security setting
Dim oldSecurity = xlApp.AutomationSecurity
' Disable macros
xlApp.AutomationSecurity =
Microsoft.Office.Core.MsoAutomationSecurity.msoAutomationSecurityForceDisable
' Find & open WorkbookType workbook files in ProjectFolder
Dim info As New DirectoryInfo(CurrentProjectFolder)
For Each fileItem As IO.FileInfo In info.GetFiles
If fileItem.Name.Contains("~") Then
' Ignore temporary files
ElseIf fileItem.Name.Contains(WorkbookType) AndAlso fileItem.Name.Contains(".xls") Then
xlApp.AskToUpdateLinks = False
Dim wb = xlApp.Workbooks.Open(CurrentProjectFolder & "\" & fileItem.Name, UpdateLinks:=False)
xlApp.AskToUpdateLinks = True
End If
Next
' Restore macro security setting
xlApp.AutomationSecurity = oldSecurity
The xlsm file may have ActiveX controls that are connected to VBA macros. If a VBA macro produces an error, is it possible to catch the error in the .NET Add-In? The error may include "macro not found"
COM add-ins (represented by VSTO add-ins) and VBA macros are entirely different entities. You can't handle VBA errors in COM add-ins, or the opposite. But you may react to the application events, see Object model (Excel) for the list of available events.
The xlsm file may have it's own ribbon attached to the file. Is it possible to inhibit the xlsm's ribbon from being added?
To prevent the custom ribbon UI from loading you need to edit the file by removing the ribbon XML customizations contained inside the Excel file. VBA doesn't deliver any UI customizations nowadays. You can use the Open XML SDK for editing open XML documents on the fly from VSTO add-ins without involving the host application or its object model.
I'm trying to open an excel file in SharePoint through a vba code in another local excel file. However, it gives me a Dialog Box and lets me save the file instead of directly opening in Excel.
Below is the code I used. Would be very grateful for your help. Thanks.
Dim wb AS Workbook
FilePath = "https://company.sharepoint.com/sites/Folder1/Folder2/Filename.xlsm"
Set wb = Workbooks.Open(Filename:=FilePath, UpdateLinks:=0)
I had this issue also. First, you have to fix something in the excel options. So, go to File > Options > Advanced > then scroll down until you see Link Handling > then select the box that says "Open Supported hyperlinks to Office in Office Desktop Apps". Next, I used the coding below to get the link to work. you just need to reply the part of the coding with you sites url sharepoint file. the only issue I came up with is that you have to run the coding below, wait for the file to completely load, and then you can run macros on this file.
Sub OPEN_YRLY()
'
' OPEN_YRLY Macro
'
'
Range("C1").Select
ActiveWorkbook.FollowHyperlink Address:="https://aramark365-my.sharepoint.com/:x:/r/personal/......", NewWindow:=False, AddHistory:=True
End Sub
I have an SSIS Script Task that calls an Excel workbook macro. This Excel macro uses an Excel AddIn (xlam) for logging. When the code runs it blows up unless during debugging, I put a breakpoint in the workbook, and then step through the Excel part. If I step through it once, my process then can run via SQL Server Agent, and in automation again. Any idea why I need to put in a breakpoint to fix the process?
Here is my sample SSIS Script Task Code:
Dim xlApp As Excel.Application = Nothing
'
Try
xlApp = New Excel.Application
xlApp.Visible = True
xlApp.Application.DisplayAlerts = False
xlApp.Workbooks.Open(strExcelDriverFile)
xlApp.Run("CreateReport")
Dts.TaskResult = ScriptResults.Success
xlApp.Workbooks.Close()
xlApp.Quit()
Catch ex As Exception
xlApp.Quit()
Dts.TaskResult = ScriptResults.Failure
End Try
Here is my sample Excel Code:
Sub CreateReport
'Log using the addin
LogHWMsg Replace(Replace("Starting Macro", "'", ""), """", ""), GExecGuid, 0, 1, ThisWorkbook.Path, ThisWorkbook.Name, _
ActiveWorkbook.Path + "\" + ActiveWorkbook.Name, Environ("UserName")
'Do some stuff...
End Sub
Excel Automation does automatically not load add-ins. You need to specifically load them via code.
The following example is from Loading Excel Add-Ins at Runtime (Written by: Jeremy Espenshade)
The following options are available if you want to do this.
1.) Application.RegisterXLL
a. This is a method which can be called from VBA which loads an XLL at a specific location and registers the functions and commands contained in the XLL.
2.) AddIns.Add
a. This is a method which can be called from VBA which loads any type of add-in (XLL, XLA or XLAM). After loading the add-in, perform step 3 to open it.
3.) AddIn.Installed = true
a. Once you have a reference to a loaded add-in, set AddIn.Installed = true to cause the add-in to be opened.
b. Note that add-ins that are known when Excel is started with the /automation switch will already be marked as "Installed", but they are not opened. In this case, Set Installed = false before setting Installed = true
Private Sub Workbook_Open()
Dim success As Boolean
Dim myAddIn As AddIn
' Load XLL
success = Application.RegisterXLL("c:\myaddins\myxll.xll")
' Load and install new XLAM
Set myAddIn = Application.AddIns.Add("c:\myaddins\myxlam.xlam")
myAddIn.Installed = True
' Load known XLAM
For Each myAddIn In AddIns
If myAddIn.Name = "myknownaddin.xlam" Then
myAddIn.Installed = False
myAddIn.Installed = True
End If
Next
End Sub
Edit:
The OP has asked that I include the technique that worked for him; i.e. activating the add-ins that are available to the user account under which Excel is executing.
The AddIns object is a property of the Excel.Application object. When you are using Excel automation, the Excel application will not automatically load the AddIns that would be loaded in an interactive session. Therefore, you need to use the proper technique demonstrated above to load the add-in based on its type.
Example Activating Known Addins:
xlApp = New Excel.Application
For Each addin As Excel.AddIn In xlApp.AddIns
If Not String.IsNullOrWhiteSpace(addin.Path) Then
addin.Installed = True
End If
Next
Please take not that the code verifies that the Path property is not empty. This can be cause by an add-in that was uninstalled.
Excel is also a pain about maintaining links to previously loaded add-ins. In fact the only way to remove on from the list is to make the the file unavailable from the originally loaded path and to specifically ask Excel to remove it via a dialog window once Excel can not find the add-in. Therefore, a Known add-in may not be accessible. To make this worse, setting the Installed property on an inaccessible add-in does not throw an error.
However an error will be thrown if you try to access any member of the unloadable add-in.
We have a product based on a set of Excel workbooks which runs on Excel 2003 onwards. Some of the workbooks open other workbooks in the same directory to use as data stores. Recently, in trying to port this to the Mac Excel 2011 platform, we converted the workbooks from .xls to .xlsm format. After a struggle with a log of compatibility issues, we have the product working on Excel 2007 onwards.
However, when we went back to test on Excel 2003 with the Converter module installed, our self-relative workbook links all break. This is because the converter makes a copy of the workbook in the users Temp directory which is not anywhere near the product directory. The user has a choice of where to install the product, so the path to the product directory has always been self-relative, which has worked fine up until now. Oddly enough, once the workbook is open, if you have run the Workbook_Open code, it returns the correct path. Only when the work book is actually opening, do you have the problem. e.g.
Private Sub Workbook_Open()
Dim appPath As String
Dim FileName As String
. . .
appPath = Me.Path
#If Win32 Or Win64 Then
FileName = appPath & "\" & "MMDataStore.xlsm"
#Else
' MAC support
FileName = appPath & ":" & "MMDataStore.xlsm"
#End If
MsgBox FileName
Application.Workbooks.Open FileName
MsgBox "Activate"
Workbooks("MMDataStore.xlsm").Activate
Me.Activate
...
The first time through, as the workbook opens, the message box indicates the Filename path (appPath) is in the Temp directory (e.g. C:\Users\njohnson\AppData\Local\Temp\MMDataStore.xlsm. If you then open up Microsoft Visual Basic and step through the same workbook open code, it now shows the sheet as being open in the correct directory. Does anyone have any thoughts on how to work around this?
Thanks, Neil
This appears to be a Microsoft bug. Our workaround was to move the code to open the workbook into the function that required it, just as it required it. e.g. When the user wanted to retrieve data from the workbook or store data to the work book, we would check if it was already open, and if not, open it at then. By this time, all of the internal pointers to the workbook seem to have been resolved, and the Workbook open worked correctly. This solution works on Excel 2003 with the converters.
Currently I'm writting VB functions and save them as an Excel addin .xlam file.
I want to have a .bat script so as to quickly deploy those addins.
Currently, to activate my .xlam addins, I have to Open Excel - File - Option - Addins - Browse to addin files... as below screenshot. This is absolutely manual, repeated & tiring thing to do.
So my need is to automate the activation process.
I was looking for exactly the same sort of thing this morning. I will eventually try something like this out, but I haven't yet. So, here is what I have come to so far:
http://msdn.microsoft.com/en-us/library/microsoft.office.interop.excel.addins2.add.aspx
This is an example about how to use Excel automation from C#. From what I see, all these automation interfaces are really COM interfaces, so you are not restricted to C# or Visual Basic (maybe you can use some fancy scripting of Windows to work with them? what I will try is to use python with pywin32, but that's only because it suits my taste).
Then, for registering the addin(s), check this method:
http://msdn.microsoft.com/en-us/library/microsoft.office.interop.excel.addins2.add.aspx
I actually saw an example somewhere about how to use it, but I can't find it right now.
Anyway, these are just ideas. I'm very interested on knowing how it all ends ;-)
you can insert this code in your *.xlam in the sheet "ThisWorkBook" this code install and activate the current AddIns, just by opening
Private Sub Workbook_Open()
Dim oXL As Object, oAddin As Object
URL = Me.Path & "\"
normalUrl = Application.UserLibraryPath ' Environ("AppData") & "\Microsoft\AddIns"
AddinTitle = Mid(Me.Name, 1, Len(Me.Name) - 5)
If URL <> normalUrl Then
If MsgBox("Can you Install AddIns ?", vbYesNo) = vbYes Then
Set oXL = Application ' CreateObject("Excel.Application")
oXL.Workbooks.Add
Me.SaveCopyAs normalUrl & Me.Name
Set oAddin = oXL.AddIns.Add(normalUrl & Me.Name, True)
oAddin.Installed = True
oXL.Quit
Set oXL = Nothing
End If
End If
End Sub
After one manually added time, we can update the addin by copy the addin file to Excel addin lair. Here is the .bat script to do it.
set fipAddin=".\FIPphase2.xlam"
set excelAddinLair="%APPDATA%\Microsoft\AddIns"
copy %fipAddin% %excelAddinLair%
Hope it helps!