I need help reguarding the following code written in Visual Basic 6.0.
Private Sub cmdExcel_Click()
Dim obj As Object
Set obj = CreateObject("Excel.Application")
On Error Resume Next
MkDir "c:\temp"
On Error GoTo 0
MousePointer = vbHourglass
On Error GoTo err
objGrid.m.ExportToXLS "c:\temp\test.xls"
obj.Workbooks.Open "c:\temp\test.xls"
obj.Visible = True
obj.Interactive = True
On Error GoTo 0
err:
MousePointer = vbNormal
End Sub
The enviroment: Windows 10, Office Excel 2016.
The problem: the workbook doesn't show up, but I can still find an Excel instance in Task Manager. If I shut down the instance I can find the Excel in c:\temp and the application starts working again.
The goal: show the Excel just created.
Do you have any solutions?
Thanks in advance.
Sara
I found the solution.
The problem wasn't in the code but in some Excel's settings.
First, I modified the code in order to get a more detailed error. Basically I switched the two instructions which allow Excel App to be visibile and the file to be opened:
obj.Visible = True
obj.Workbooks.Open "c:\temp\test.xls"
In this way, I was able to open Excel App and read the reason why the file could not be opened.
As you can see the file type is Excel 4 Worksheets which is blocked on opening.
I had to go Trust Center and disable it.
Just to be sure, I disabled also Excel 4 Workbook.
After performing the steps above, my app worked.
Related
I have an Access database split into a front and back-end, still using the mdb file format as user level security is required. Part of the db functionality is to create reports in Excel (via VBA). One of my routines uses a blank excel workbook as a template and copies it to paste the report data into. Users in the office have MS Office 365 on their desktop machines and each user has their own copy of the front-end database. The back end database sits on a server. These users have always been able to run this report and when I recently gave them an updated copy of the front-end they could still run this report. There was no change to the code that creates this report in the updated front-end database.
However there are some remote users on RDS. They were using a previous version of Office and this report worked. They were updated to Office 365 and the report worked. I gave them the updated front-end and they could not run the report. Below is the code:
Dim objExcel As Excel.Application
Dim objReportDataWrkbk As Excel.Workbook
'open Excel
On Error Resume Next
'Try first to use an existing instance.
Set objExcel = GetObject(, "Excel.Application")
If Err Then
'Excel wasnt running
Set objExcel = CreateObject("Excel.Application")
End If
On Error GoTo Err_ExportExternalReferralDataToExcel
'copy Excel template
objExcel.SheetsInNewWorkbook = 5
Set objReportDataWrkbk = objExcel.Workbooks.Add(strPathToExportTemplateFiles & strTemplateName)
objReportDataWrkbk.SaveAs strPathToTempExportFolder & strFileName
For RDS users the SaveAs line throws the error 'Error 9 subscript out of range'
I have stepped through the code and the part that starts Excel works - I can see Excel open.
The line that copies the workbook works - I can see the workbook open in Excel.
It hits the SaveAs line and I get my error.
I have done a Debug.Print of strPathToTempExportFolder & strFileName - and the path is valid and the file name is not something odd that may prompt an error.
I have tried modifying strPathToTempExportFolder to save in another location and I still get the error.
I am told by the office IT that the users have relevant network permissions to copy files and save files in the locations I have been trying.
Is there something blindingly obvious that I am missing here. Any help greatly appreciated.
I have VBA code in Excel that calls a Word file in a specified local folder.
For some users it turns the following error:
The macros in this project are disabled. Please refer to the online help or documentation of the host application to determine how to enable macros
The error appears as the code is supposed to move from Excel to the Word file.
What I've tried so far:
Excel Trust Center:
The entire location (including subfolders are trusted).
"Allow documents on a network to be trusted" is checked.
Disable all macros with notification is "checked".
I cannot change this as it is greyed out. However, this setting is the same for all users.
Protected view is disabled.
Word Trust Center
Protected view is disabled.
Opening the Word file doesn't produce any "enable macros" notifications.
The normal way to grey that out on purpose (maybe your users' IT sets this through gpo?) is a registry key, where 16.0 is the version you have installed
[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Excel\Security]
"VBAWarnings"=dword:00000001
Some other things to troubleshoot:
Can they create and run their own macro?
Can they run a different macro in a different document?
Does anyone have a different version of Excel?
Are the excel and word file both local to the user PC?
Do the users have Developer settings enabled?
Does anyone have different settings in Macro Settings > Developer Macro Settings?
Is Windows blocking the excel file? Right-click the file > properties > General:
There's also this specific GPO that only blocks macros from the loosely-defined "Internet"
I had a similar issue some time ago. When opening a word document from within an Excel macro, everything worked fine for me. But on another PC, the macro simply stopped with a message indication that macros where disabled.
The issue could be solved by changing the Application.AutomationSecurity property for the word app to msoAutomationSecurityLow.
It is important to set that property back to its original value after code execution.
You can try the following code example.
Option Explicit
Sub OpenWordsFilePathWithLowSecuritySettings()
Dim sFilePath As String
Dim wrdApp As Object
Dim wrdDoc As Object
Dim lAutomationSetting As Long
'The path to your word file
sFilePath = "C:\Users\micha\Desktop\example file.docx"
Set wrdApp = CreateObject("Word.Application")
wrdApp.Visible = True
'Save word app automation security so we can restore it afterwards
lAutomationSetting = wrdApp.AutomationSecurity
'Error handling to make sure the automation security is reset even if an error occurs
On Error GoTo ErrorHandler
'Change the automation setting to low security
wrdApp.AutomationSecurity = msoAutomationSecurityLow
'Open word document
Set wrdDoc = wrdApp.Documents.Open(sFilePath)
'Your code - do something with the word file
'
'
'
ErrorExit:
On Error Resume Next
'Close the word document
wrdDoc.Close
'Reset the word automation security
wrdApp.AutomationSecurity = lAutomationSetting
wrdApp.Quit
Set wrdDoc = Nothing
Set wrdApp = Nothing
Exit Sub
ErrorHandler:
MsgBox "An error occured: (Code: " & Err.Number & ", Description: " & Err.Description & ")", vbCritical, "Error"
Resume ErrorExit
End Sub
When using the Documents.Open("XX") command in excel. My excel prompts the window where it says that the document is lock for editing, by ME. Which isn't the case.
This command does seem to work when i'm using microsoft word/excel 2010 at work. But at home, using office 2016, it doesn't. This goes for my personal laptop with office 2016 aswell.
The following code is used:
Sub test()
Dim wordDoc As Word.Application
Dim testDoc As Word.Application
Set wordDoc = CreateObject("Word.Application")
Set testDoc = wordDoc.Documents.Open("C:\Users\Me\Desktop\Test.docm")
' Do stuff
End Sub
My thoughts:
Office 2016 seems to open a 'Shadow file' which gives the document 'Open' status. But when restarting my PC the code simply does NOT work. Giving an 'Filename' error, upon restarting the code the 'Locked for editing' error appears.
My question:
Am i using the wrong approach on opening a document in Office 2016? If so, what is the right approach? If not, are there settings that need to be changed in order for this to work?
Thanks in advance,
I've had this happen before, the issue for me was that a previous run of the macro wasn't able to close the file properly. Give this thread a read:
Application.Quit command not closing the entire Excel Application
You could test to see if this is the case by "End Task"ing all MS Word instances and running your macro again, If it's able to run the first time, then this is your issue.
Also, This is the code I used for testing. Dim'ing the variables as "Word.Application" didn't work for me, so if my earlier suggestion doesn't work then try just "Object" instead:
Sub openWord()
Dim wrd As Object
Dim doc As Object
Set wrd = CreateObject("Word.Application")
wrd.Visible = True
Set doc = wrd.Documents.Open("C:\Users\name\Desktop\doc.docx")
doc.Close
wrd.Quit
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.
I wrote a VBA macro in Excel 2007 on Windows XP to copy data from an excel spreadsheet into a powerpoint presentation.
When this macro enabled spreadsheet was run on a fresh install of Windows 7 it fails.
So I pulled out the code that fails to pin point the problem and it seems to fail when trying to open an existing powerpoint file. I have tried running this code in both Office 2010 and Office 2007.
The code I am trying to use it (just the problem parts shown below)
Sub test()
Dim PowerPointApplication As PowerPoint.Application
Dim PowerPointFile As PowerPoint.Presentation
Set PowerPointApplication = CreateObject("PowerPoint.Application")
Set PowerPointFile = PowerPointApplication.Presentations.Open("PATH_TO_FILE\test.pptx")
End Sub
The macro fails on the Presentations.Open line above with the following error
Run-time error '-2147467259 (80004005)':
Method 'Open' of object 'Presentations' failed
I have already enabled the PowerPoint 12.0 Object Library in the references settings in the VBEditor for the spreadsheet. All the other references match exactly with the file that runs without error on my Windows XP box.
I have looked all over the web for an answer and cant find anything. I read something about Windows 7 and offline files, so tried turning that off but it didnt help.
I am logged in as an administrator user as well, and tried moving the pptx that I am opening to other directories as well with no success.
I am running the following version of Windows:
Windows 7 Professional
Service Pack 1
64 Bit
Any help would be appreciated!
Is PATH_TO_FILE a variable (or constant)??
If so shouldn't it be
PowerPointFile = PowerPointApplication.Presentations.Open(PATH_TO_FILE & "\test.pptx")
This does work in office 2016 on Win7 SP1 64bit OS
Should be good for Office 2010.
Could be John's advise on the path to file, also.
Sub test()
Dim PowerPointFile As PowerPoint.Presentation
Dim PPTObj As Object
Set PPTObj = CreateObject("PowerPoint.application")
Set PowerPointFile = PPTObj.Presentations.Open("C:\test.pptx")
End Sub