I have to create an excel file in VB.NET to make some calculations trough a excel add-in (if you are asking, no, recreating the add-in inside the program itself is not an option), I have done some research and according to the microsoft.docs website I would have to use my application variable (aka appXl) and write appXl.AddIns.Add([filename]), but it fails every time, again according to the microsoft.docs I should open the workbook.
I tried using appXl.AddIns2.Add([filename]), but it failed too, I tried various solutions found on the internet, but none seem to work, I also tried using the title, or the directory, but it doesn't work
code:
vb.net
Imports Microsoft.Office.Interop
Private appXl As Excel.Application
Private wbXl As Excel.Workbook
Private shXl As Excel.Worksheet
Private AddinXl As Excel.AddIn
Private dataDirectory As String = (String.Format("{0}\Data\", Environment.CurrentDirectory))
Private Sub Main_Load(sender As Object, e As EventArgs) Handles MyBase.Load
dataDirectory &= "AnimalFeed.xlsx"
appXl = New Excel.Application
wbXl = appXl.Workbooks.Open(dataDirectory)
shXl = wbXl.Worksheets("solver")
AddinXl = appXl.AddIns.Add("wba.xlam")
End Sub
it should load the plugin and then be able to use all of its functions inside vb.net, but the debug stops to the AddinXl = appXl.AddIns.Add("wba.xlam") line and it just says "Add method of AddIns class failed".
Have you added Excel in your references?
I'm sorry I can't guide you through this as I haven't used VB.net in ages, but in order to use the Excel objects, you'll need the reference.
You'll know if you have added it when type Excel, the list of possible options will appear.
If not, look for Tools -> References and find Excel probably under Microsoft first. Google vb.net with your version numbers (.Net and Excel) to get an exact guide.
Related
I have a vb6 program that calls Macros from an Excel file.
Until recently it worked fine (for years), but now it throws an error.
We get a runtime 438 "Object doesn't support this property or method" error.
As an example you can use this simple vb6 program:
Set App = CreateObject("Excel.Application")
Set wrkbook = App.Workbooks.Open(fileName)
App.visible = True
wrkbook.Test
The above code doesn't work anymore.
Instead, if we replace the last line with this:
wrkbook.Application.Run "ThisWorkbook.Test"
it works.
The Excel reference used for this, was "Microsoft Excel 16.0 Object Library"
This has been tested against Excel 2010, 2013, Excel365 with the same results.
Also security settings are all set off in Excel.
Before changing my entire codebase and use Application.Run, I would know why this is happening.
Also using Application.Run has also some downsides, like calling both private & public subs and exceptions thrown are not propagated back to vb6.
Are there other considerations for using Application.Run?
Did Microsoft changed something lately (Scurity update), or am I doing something wrong?
I found the problem, thanks to #UuDdLrLrSs comment.
Problem was the use of early binding.
All Excel objects should use late binding.
More specific, the workbook should be declared as object:
Dim wrkbook As Object 'New Excel.Workbook
Otherwise it cannot recognize/find your Macro method.
I have following code, which check-out (locks) file with ID = 1, in Sharepoint Library Document application:
Sub LockAccessDatabase()
Dim context As New ClientContext("https://web.page.net/sites/MySite/")
Dim mylist As List = context.Web.Lists.GetByTitle("MyLibraryDocument")
Dim listItem As ListItem = mylist.GetItemById("1")
Dim file As File = listItem.File
file.CheckOut()
context.Load(file)
context.ExecuteQuery()
End Sub
It is using references:
Microsoft.SharePoint.Client
Microsoft.SharePoint
This code is working well, in Visual Studio, but then I need to use it in Excel application (translate to VBA). Unfortunatelly, when I try to import library to Excel Vba, I got following error:
For what I found - I need to declare necessary functions in the code. I need some support information how to do that. How can I know which functions I need to declare? How can I find necessary functions?
I've spent so much time searching for this solution, and now it seems that I stuck just before finish.
I am attempting to use the edrawings VBA api via excel. I have downloaded the edrawings SDK and it seems as though the api only runs through a user form. I have made a few vba macros for solidworks via excel but unlike solidworks there is very limited documentation. I simply want to make a connection to the API, after which I should be able to take it from there.
For right now I would simply like to open up a solidworks drawing in edrawings via excel. So something like the following:
Sub OpenDrawing()
Dim xlBook As Workbook
Dim xlsheet As Worksheet
Dim eDraw As New EModelViewControl
Dim FilePath As String
Set xlBook = ActiveWorkbook
Set xlsheet = xlBook.Sheets(1)
FilePath = Range("B1").Value
eDraw.OpenDoc FilePath, False, False, True, ""
End Sub
As an example, Range B1 is the following "C:\ _EngVault\000S\090\090-40400-01.SLDDRW". I have activated the EModelView2018 Type Library and running edrawings 2018. Again, once I can figure out how to connect to the program I should be good but I am unable to make it that far.
Also, do I need a user form for this or did I misunderstand?
Thank you in advance,
FFS88
Also, do I need a user form for this or did I misunderstand?
Yes the eDrawings API is an OLE programming interface to eDrawings and is implemented as a Microsoft ActiveX control.
So you have to place the ActiveX control on your form and access the api through this control:
Me.EModelViewControl1.OpenDoc path_to_edrawings_file, False, False, False, ""
It is not possible to start a new instance or connect to a running instance as you may know from the SOLIDWORKS API.
If I Run
Sub test()
Dim Template_Excel_Instance As excel.application
Set Template_Excel_Instance = CreateObject("excel.application")
End Sub
my code breaks with an error "Automation Error, Library not registered"
If I run
Sub test()
Dim Template_Excel_Instance As object
Set Template_Excel_Instance = CreateObject("excel.application")
End Sub
It runs fine. Is there any way to fix this? Reason I ask is that this issue only affects one PC, despite having the same references as all other PCs. The first error is not coming up anywhere else
Does that PC have a different version of Excel?
The problem is with As Excel.Application. If you don't have the appropriate reference defined, then the VBA compiler will not recognise the type. Yes, VBA does have a compilation step. If you do have the reference defined, then this is sensitive to the application version (just the major part of the application version I think), so is therefore inherently non-portable.
In your latter example, you are using late binding, so only COM object registration is required, not any specific library to be added to your project. For portability, this is the way to go.
Firstly, have you tried repairing the install?
Secondly, is there a reason you are instantiating a second instance of Excel?
Thirdly, let's get a grip on what is happening, please run this code and report back.
Option Explicit
Sub TestWhatVersionDoesCreateObjectReturn()
Dim obj As Object
Set obj = CreateObject("Excel.Application")
Debug.Print obj.Version
End Sub
Sub TestWhatOtherVersionsAreCreatable()
Dim lLoop As Long
For lLoop = 7 To 16
Dim obj As Object
Set obj = Nothing
On Error Resume Next '///set break on unhadnled errors
Set obj = CreateObject("Excel.Application." & CStr(lLoop))
On Error GoTo 0
If Not obj Is Nothing Then Debug.Print obj.Version
Next
End Sub
Also, look for multiple installations of Excel. The code at this blog page will read your registry and write the results to an Excel worksheet. You say you have repaired the install but there might be other Excel installations interfering. The code in that blog will highlight multiple Excel installs.
Ok, from your feedback you say all the Excel libraries version return 14, implying no multi version installs. Hmmm, we ought to consider that actually the library that error is complaining about isn't Excel but a dependency.
Other possible leads
Social MSDN - automation error. Library not registered - solved by cleaning registry of legacy "Microsoft.Office.Interop.Excel" keys
We have an excel spread sheet which we use and it works for most machines but bombs out with 'Compile Error in Hidden Module - General' on others, and the reason appears to be due to missing References.
We check that Macros is enabled but still doesn't help.
Since we protect this excel spread sheet with a password, we don't want to be giving this password out to our users to check the References, and wondered if anyone had any idea how I can add VBA code to check whether the References required for the excel spread sheet is there and if not then bring up a message box to advise the user.
The References we use are as follows:
Visual Basic For Applications
Microsoft Excel 11.0 Object Library
Microsoft Forms 2.0 Object Library
Microsoft Windows Common Controls 5.0 (SP2)
Alternatively, if anyone has any other suggestions on how to go about this problem, that would be great.
The only reference you have listed that could possibly be missing is the common controls. The rest are default in every version of Excel. The Forms one is only if you have a userform or explicitly set it, but that's not your problem. Common Controls is your problem. It doesn't ship with Office anymore. If you have Visual Studio or VB6 you probably have it. Or an old version of Office like XP Developer Edition.
Anyway, you can check for the existence of the OCX file in the System folder. I don't think it's required to be in that folder, but I've never seen it anywhere else.
It's been quite a while since I've seen a reference to 5.0, so I included how to find 6.0 in the code below. Check to make sure you know what version you're using.
In a standard module:
Private Declare Function GetSystemDirectory Lib "kernel32" Alias "GetSystemDirectoryA" (ByVal lpBuffer As String, ByVal nSize As Long) As Long
Public Function HasCommonControl() As Boolean
Dim sFolder As String
Dim lReturn As Long
Const lSIZE As Long = 255
Const sDLLNAME As String = "COMCTL32.OCX" 'For windows common control 5.0
'Const sDLLNAME As String = "MSCOMCTL.OCX" 'For windows common control 6.0
sFolder = Space(lSIZE)
lReturn = GetSystemDirectory(sFolder, lSIZE)
sFolder = Left$(sFolder, lReturn)
HasCommonControl = Len(Dir(sFolder & Application.PathSeparator & sDLLNAME)) > 0
End Function
Having said all that, why are you using common controls? If it's for a treeview on a userform, then check out this all-vba treeview
http://www.jkp-ads.com/articles/treeview.asp
Since jkp wrote that, I haven't used common controls. So few normal-people PCs have it installed that it's just a pain.
Depending on a reference to a specific Excel or other component version is one possible problem. Switching to late binding would solve that problem, so long as you're careful not to use any commands/objects/methods/properties that are supported in one version and not another.
Following up on RowanC's link (good choice), you can add a reference to Excel, for example and write your code like so:
Dim xlWks as Excel.Worksheet
'Dim xlWks as Object
Once everything's debugged, remove the Excel reference and change the declarations to:
'Dim xlWks as Excel.Worksheet
Dim xlWks as Object
That gives you the benefit of intellisense while coding/debugging but removes the dependency on a specific version of Excel later.
Might be mistaken, but IIRC the Common Controls component is part of Visual Basic, not Office, so unless you distribute it and register it along with your app, it might not be present on some systems.
To try late binding, which doesn't need the references setup (although it may have a performance hit, and it will mean that autocomplete doesn't work in your code) instead of calling excel in the following way:
Dim oExcel As Excel.Application
Set oExcel = CreateObject("Excel.Application")
try calling it this way, and drop the reference to the excel object model.
Dim oExcel As Object
Set oExcel = CreateObject("Excel.Application")