Vbs on Excel Starter 2010: activex component can't create object Excel.Application - excel

I have a new pc with Windows 7 and Office Starter 2010 pre-installed. If I launch the following simple vb script (from command line: cscript testScript.vbs):
Dim xlApp
Set xlApp = CreateObject("Excel.application")
xlApp.visible = True
Set xlWorkbooks = xlApp.Workbooks
Set xlWorkbook = xlWorkbooks.Open("C:\path\myFile.xls")
xlWorkbook.ActiveSheet.Rows("1:2").AutoFit
xlApp.visible = False
xlWorkbook.Save
xlWorkbook.Close("C:\path\myFile.xls")
xlApp.Quit
Set xlApp = Nothing
it returns this error: activex component can't create object 'Excel.Application'.
I don't understand if the error is due to Starter limitations (http://office.microsoft.com/en-us/starter-help/excel-features-that-are-not-fully-supported-in-excel-starter-HA010374501.aspx), and I found dissenting opinions on the web.
Is there a way to make it works using Office Starter version?

Despite this is already very aged question, I haved decided to post the following information only to help other googlers.
Since you are trying to create an instance of Excel.Application outside VBA, there's a good chance of being succeeded if you install an updated version of Microsoft Excel Viewer on target machine. This will allow you to access Excel's API.
Bear in mind, that Excel Starter Edition does not support macros, along with other important limitations.
Cheers!

Related

Task Scheduler failed to run the Excel VBA Macro

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?

Weird issue when trying to open Excel Application from VBScript especially when the script is not running with elevated access/privileges

As I mentioned in the Q-title, I have a VBScript which I am sure was working fine in Windows 10 with Microsoft® Excel® LTSC MSO (Version 2205 Build 16.0.15225.20278) 64-bit Excel version and once I made sure that ClickToRunSvc service was running, and then when I ran this VBScript(without any elevation) it did open any Excel secured sheet with password, so that I didn't have to enter password everytime I wanted to open the sheet(I know not very secure, but this is my system behind firewall, so not much worried about it there).:
Sub OpenChosenLockedSheet(ChosenFile)
AdminElevate
Set objExcel = CreateObject("Excel.Application")
objExcel.SendKeys "% x" : objExcel.Visible = True : objExcel.SendKeys "% x"
CreateObject("Wscript.Shell").AppActivate GetObject(, "Excel.Application").Caption
Set objWorkbook = objExcel.Workbooks.Open(ChosenFile, , , ,"<password>")
Set objExcel = Nothing : Set objWorkbook = Nothing
End Sub
But now after fully upgrading the OS to Windows 11, this same above script, running with same Office Excel version, doesn't open the Excel.Application at all and throws the below(also very infamous) error, unless I self-elevate the above script(that's why AdminElevate is uncommented) and open the secured sheet:
Error: ActiveX component can't create object: 'Excel.Application'
Code: 800A01AD
So my query: Is this part of bigger change Microsoft made when it rolled out Windows 11 and I missed or there needs to be some extra coding or quick-fix done to make this script work without admin-elevation ? Anyone feel free to help out.

eDrawings API via Excel

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.

Error running Excel Macro VBScript

Running a job from AutoSys and I am getting an error.
VBS runs an excel macro.
VBS code :
Option Explicit
Dim xlApp, xlBook
Set xlApp = CreateObject("Excel.Application")
On Error Resume Next
set xlBook = xlApp.Workbooks.Open("Z:\Confidential Restricted\Weekly_HR_Employees_Macro.xlsm",0, False)
xlApp.Run "Weekly_HR_Employees_Macro.Weekly_HR_Employees_Macro"
xlBook.Close True
xlApp.Quit
set xlBook = Nothing
Set xlApp = Nothing
Error:
Microsoft VBScript runtime error: ActiveX component can't create object: 'Excel.Application'
You are using GetObject syntax with CreateObject method. You need to use:
Set xlApp = CreateObject("Excel.Application")
Check this answer for more details.
Although the script runs on my machine, it would not run on the machine that the AutoSys job was using. I eventually found that the machine that was being used by the Autosys job does not have Microsoft Office installed.
You can use GetObject("Excel.Application"), but you need to make sure you open up an instance of excel before you use it. GetObject will get a reference to this open instance of Excel and let you use that.

Producing Excel files in ASP on IIS7.5

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.

Resources