I have the following script "MyTest.vbs" :
Dim objXLApp
Set objXLApp = CreateObject("Excel.Application")
objXLApp.visible= True
objXLApp.DisplayAlerts = false
objXLApp.Workbooks.Open "F:MyFolder\test.xlsm"
objXLApp.Run "test.xlsm!Module1.main"
objXLApp.Workbooks("test.xlsm").Save
objXLApp.Workbooks("test.xlsm").Close
When I run the script, the following error appear :
Be careful! Parts of your document may include personal information that cannot be removed by the document inspector.
I know that I can fix this error manually, but I would like disable this error with code.
Someone knows how ?
There's a VBA (not vbs) method called Workbook.RemoveDocumentinformation(xlRDIAll). Take a look at this https://learn.microsoft.com/office/vba/api/excel.workbook.removedocumentinformation
You should just add this to your Module1.main.
Related
I'm trying to implement a bootstrap installer for my add-ins workbook, such that I can easily install the add-in for new users and send out updates. It works fine on my machine, but when having others test it, I get a runtime error when I try to call Set AI = Application.AddIns.Add(fileName:=fullPath, copyfile:=True). Specifically, the error is "1004: Unable to get the Add property of the AddIns class". I thought this was because the user needed to have "Trust access to the VBA project object model" enabled, but the error seems to occur even after they've toggled that box.
Other things I've checked:
The fullPath to the add-in is valid and the user can access the directory and the file
The user has the folder located at Application.UserLibraryPath
Any ideas?
Figured it out. It appears that the issue isn't one of permissions, but rather of whether a workbook is already open. Opening any workbook before running the Addins.Add prevented the error from occurring so I've simply added that into the program:
If Application.Workbooks.Count = 0 then Set wb = Application.Workbooks.Add()
Set AI = Application.AddIns.Add(fileName:=fullPath, copyfile:=True)
If not wb is nothing then wb.Close
Duke, perhaps it's the Trust Center settings on the recipients' machines. I have found this and may be helpful.
Best,
Danny
Check out VBA videos on ExcelVBADude on YouTube.
I'm fixing some code written by a colleague and I've come across this hurdle where an Excel document is opened from a Sharepoint and the ChangeFileAccess method is run to change it to Read/Write. The method fails with error code 1004. The file opens so everything up to that point is working.
I can't see why it won't work, I'm hoping someone more knowledgeable than I can!
I've removed the file path and document name for the sake of anonymity.
I'm using Office 365, code in question below:
Dim ObjFileA, ObjfileB As File
FilePathA = "filepath" & fileName
Set FSO = CreateObject("Scripting.FileSystemObject")
Set App = CreateObject("Excel.Application")
Set ObjFileA = FSO.GetFile(FilePathA)
Set wbA = Workbooks.Open(ObjFileA, False, False)
wbA.Activate
wbA.ChangeFileAccess (xlReadWrite)
Set wbA = Workbooks(fileName)
Is your file already being opened as Read-Write?
I just encountered a similar problem to what you describe (Err 1004 when changing the access method, though in my case I was attempting to change the access to Read-Only on a file that was already Read-Only.)
After some testing, I get the error every time if I try to invoke wkbk.ChangeFileAccess to "change" the access type to be the same as the current access type.
If you find that the workbook might already be Read-Write, then I suggest a change to :
If wbA.ReadOnly then wbA.ChangeFileAccess (xlReadWrite)
Our code essentially does the following:
1) It creates an Excel.Application object, and invokes .Workbooks.Open to open a file from a network location
2) It makes a minor change to the open Workbook
3) It invokes the .Save() method to save the workbook
This is causing a problem when the file is currently in use because
1) NO error is raised on .Workbooks.Open - The workbook simply gets opened in ReadOnly mode, but no messages or nothin' are shown to the user. So unless the user pays close attention and looks at the Title Bar, he or she will have NO idea that the document has actually been opened in ReadOnly mode
BUT the worst thing is
2) The .Save() method on the WorkBook object raises NO error WHATSOEVER. Instead it just goes ahead and saves the document to the %UserProfile%\Documents folder. Not only does it raise no error that WE can catch in code, it shows no message or warning to the USER either, so they remain blissfully unaware of the fact that they are no longer working on the original document in the Network Location, but on a local copy of same instead.
So the questions are:
1) Can we either force Excel to show a message to the END USER or raise an error on the .Workbooks.Open method so we can handle it in code? At the moment all I can do is check the workbook's .ReadOnly property, but that will give me no clue as to whether the workbook is ACTUALLY Read Only, or whether it was open in Read Only mode because it is in use by another user, let alone tell us in code, or the user through a message box, by WHOM the workbook might be in use.
2) Can we force Excel to raise an error or prompt the user on the workbook's .Save method, rather than simply saving it somewhere local without any indication to anyone!?!?
Sorry if I sound exasperated.... you should have heard the customer....
'Please note that oXApp is a Microsoft.Office.Interop.Excel.Application that has been instantiated correctly.
Dim oWBS As Microsoft.Office.Interop.Excel.Workbooks = Nothing
Dim oWBK As Microsoft.Office.Interop.Excel.Workbook = Nothing
oWBS = oXApp.Workbooks
oWBK = oWBS.Open(sFile) 'No error raised here, nothing. Document is opened in ReadOnly mode. sFile contains a UNC path to a file that is in use by another user.
oWBK.Save() 'Again, no error raised, but while oWBK.FullName points at the UNC path BEFORE the Save, it now refers to a local path in %UserProfile%\Documents
Please don't comment with anything about naming conventions, approaches, asking what the code is supposed to DO, or anything that isn't directly related to my issue:
This runs perfectly for me, everytime--A window pops up, and I select multiple Excel files and their data is uploaded into my sheet (Code not pictured). My client says he gets an error when he runs it, and naturally I assumed it was because he ran it on a Mac...but he says he gets the error on both PC and Mac. I can't recreate the error...and here we are.
Here's the code in question, the erring line highlighted in yellow:
Code for your copying:
Sub Import_Employee_Sheet()
With Application.FileDialog(msoFileDialogFilePicker)
.AllowMultiSelect = True
If .Show = True Then
End If
End With
End Sub
This is probably because he hasn't set the Microsoft Object [Version number] Library reference under Tools/References in the IDE, or because it's broken. Also see this post on how to fix the problem WITHOUT setting the object reference in order to avoid similar problems in the future.
Edit
It should read "...without setting the library reference" above.
In VBScript I'm injecting a module into excel files and then I want to run them. The injection goes fine but when I run it says it can't find it. I've put the location in the trust center so it should trust it just fine. The module has a public sub named Run as well.
Dim XL
Set XL = CreateObject("Excel.Application")
Dim book
Set book = XL.Workbooks.Open(wkpath + "\" + wkname, 0, false)
book.VBProject.VBComponents.Import "C:\MyModule.bas"
XL.Application.Run("'" + wkname + "'!Run")
The paths and names all work out. Am I doing something wrong with this? What are my next debugging steps here.
[EDIT]
Actually it looks like some references aren't being selected now so it's getting an error about user-defined type not defined, but that's not the error that I get from VBScript. I had to do what is happening manually and then I saw that error.
So I was missing a reference but the error was pretty bogus. I figured this out by stopping my process once the excel file was open and adding in the module manually and trying to run the function. So I added the following in vbscript and it worked:
book.VBProject.References.AddFromFile "path to my xlam that has the type I use"