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.
Related
I created an Excel VBA that check for data in the cells and send email with WorkBook_Open().
Option Explicit
Private Sub Workbook_Open()
'Declaring variables
Dim notifyEmailApplication As Object
Dim notifyEmailContent As Object
Dim triggerEmailApplication As Object
Dim triggerEmailContent As Object
'Create email object
Set notifyEmailApplication = CreateObject("Outlook.Application")
Set notifyEmailContent = notifyEmailApplication.CreateItem(0)
Set triggerEmailApplication = CreateObject("Outlook.Application")
Set triggerEmailContent = triggerEmailApplication.CreateItem(0)
...
I then created a VBScript to run the Excel file.
Call ExcelMacro
Sub ExcelMacro()
Set xlApp = CreateObject("Excel.Application")
xlApp.Visible = True
xlApp.DisplayAlerts = False
Set xlBook = xlApp.Workbooks.Open("....\Email Automation.xlsm", 0, False)
xlBook.Close
Set xlBook = Nothing
xlApp.Quit
Set xlApp = Nothing
End Sub
I also created a cmd file to run the VBScript on cscript.exe
cscript.exe "....\vbscript.vbs"
exit
Whenever I trigger the cmd file manually (double clicking it), the Excel Macro runs perfectly and successfully send email to the designated person.
But when I use Task Scheduler to run the cmd file, the Excel Macro does not run successfully and this line was highlighted.
Set notifyEmailApplication = CreateObject("Outlook.Application")
Notes: I already viewed a lot of forums and didn't find a fix:
In 'dcomcnfg' I already set Outlook Message Attachment to Interactive User
I tried changing Dim notifyEmailApplication As Object to Dim notifyEmailApplication As Outlook.Application, same line is highlighted
I already added Outlook Object Library as reference in Excel VBA
But when I use Task Scheduler to run the cmd file, the Excel Macro does not run successfully
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
Read more about that in the Considerations for server-side Automation of Office article.
If you deal with open XML documents you may consider using the Open XML SDK instead, see Welcome to the Open XML SDK 2.5 for Office for more information. Also take a look at any third-party components designed for the server-side execution (they don't require Office installed on the system).
I haven't touched this topic for many years, but as I remember, from a long time ago, the Task Scheduler allows, or requires, you to enter your Windows password and if the password is incorrect it won't notify you of the error, so it seems like it's working, but with the incorrect password, it won't work. Can you double-check that your Windows password is entered correctly?
Using Windows 10 (Build 1903 if that's relevant?) and 64bit Office 365 (probably relevant?) I've implemented a system that allows me to version control Excel VBA code.
I'm using the Workbook_BeforeSave method to check whether the current file is saved or not, and if it is saved, where it is saved to.
This works fine and will prompt the user as to whether they want to update the code contained within. I then thought that maybe I should in fact check if the code "needs" to be updated prior to prompting the user.
First off, I found the following question/solution: Using VBA to read the metadata or file properties of files in a SharePoint doc library
which I couldn't use without DSOFile.dll that I was able to install from here:
https://www.microsoft.com/en-us/download/details.aspx?id=8422
Here follows the code I have which doesn't work:
Private Function CheckTemplateIsNewerThanCurrentFile(ByVal templatePath As String) As Boolean
Dim templateName As String
Dim fso As New FileSystemObject
templateName = ActiveWorkbook.CustomDocumentProperties("TemplateName").Value
If fso.FileExists(templatePath & "\" & LocalTemplateName) Then
Dim objDSO As New DSOFile.OleDocumentProperties
objDSO.Open templatePath & "\" & LocalTemplateName, True, dsoOptionDefault
If Not objDSO.CustomProperties("LastCommitDate") = ActiveDocument.CustomDocumentProperties("LastCommitDate").Value Then
CheckTemplateIsNewerThanCurrentFile = False
Else
CheckTemplateIsNewerThanCurrentFile = True
TemplateLastCommitDate = objDSO.CustomProperties.Item("LastCommitDate")
End If
End If
End Function
And here (highlighted) is the error I receive trying to run the method above on an .xlsb file:
(FWIW: the reason for use of the .xlsb format is because we're working with 500K+ rows of data in the process we're carrying out. Yes, I know Excel is ABSOLUTELY NOT the tool for this but we're lumbered with it now)
I know I could have already tried changing the file format to .xlsm but because this file is version controlled that is a pain to do if the method is still likely to fail.
Thanks in advance,
Alex.
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.
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")
On an existing web application I support there is a page that is used to produce an Excel spreadsheet for some data. The Web server has Excel 2002 installed (so old...) and makes uses of automation of the Excel object to do the work.
I am fully aware that automating Excel like this is not recommended by Microsoft, but this is the way is currently works, and I am never allocated any time to look to change this.
Here is some sample code
Dim xlApp, xlBook, xlSheet
'create the Application Object and workbook object
Set xlApp = Server.CreateObject("Excel.Application")
Set xlBook = xlApp.Workbooks.Add
Set xlSheet = xlBook.Worksheets.Add
'turn off any alerts
xlApp.DisplayAlerts = False
xlApp.Visible = False
xlApp.ScreenUpdating = False
xlApp.DisplayFormulaBar = True
xlApp.CommandBars("Standard").Visible = True
xlApp.CommandBars("Formatting").Visible = True
xlApp.CommandBars("Chart").Visible = True
xlApp.CommandBars("Control Toolbox").Visible = True
xlSheet.Cells(1, 1).Value = "Test"
xlApp.ScreenUpdating = True
xlApp.ActiveWorkbook.SaveAs ("C:\Temp\Test.xls"), -4143
xlApp.Quit
Set xlApp = Nothing
The Web Server is a Windows 2003 server, running IIS6, and everything works happily. However, we are currently upgrading to using Windows 2008 servers, running IIS7.5 and the above code is no longer working. The message returned is as follows:
Microsoft Excel error '800a03ec'
SaveAs method of Workbook class failed
xxxxxx/Test_Excel.asp, line 42
The thing is, is that if I create a simple .vbs file, with the above code and run it, it all works as expected. It is only when running as an ASP page does it fail.
The folder is it trying to write to should have the correct permissions (I added 'Everyone' to it, with full access).
Does anyone have any suggestions as to why this is happening?
Thanks!
First of all I'd remove that Everyone group from the folder you're trying to write to, that's leaving open a potential security headache for another day.
There's a few different ways that your site could be configured to authenticate which will determine the identity that the Excel COM server will launch as.
However, rather than go through them all, create a script that does just this:
<%
Dim xlApp, xlBook, xlSheet
'create the Application Object and workbook object
Set xlApp = Server.CreateObject("Excel.Application")
Set xlBook = xlApp.Workbooks.Add
Set xlSheet = xlBook.Worksheets.Add
%>
Open task manager, select the "Processes" tab. Ensure that "Show processes from all users" is enabled and sort the processes by Image Name.
Browse to the script above and you should see the Excel.exe appear in the process list:
In the third column you will see the identity that Excel is running under. That's the account that needs write permissions to your c:\Temp folder.
When you do this you'll need to manually kill Excel.exe because it'll just keep running otherwise.
The only thing I can recommend is to check your App Pools in IIS7. Within the Advanced Settings of the App Pool, you may have to change the Identity account to one of the built-ins. By default in IIS7.5+, a dynamic account is used with the name of the App Pool and it appears in your Task Manager with the name.