I'm trying to programatically import Microsoft.Office.Interop.Excel namespace into my vba project. I found this site
that displays how to import it manually, but I'm giving this project that I've been working on to people that won't know how to import it. Can anybody please help?
I assume from your question that your VBA code uses a reference to the Microsoft Excel 12.0 (or other version) library - and that your user gets an error as the reference cannot be found. In this case, you have two options:
Instead of referring to the v12 library, refer to an older library, e.g. from Excel 2003. To do so, search the net for this library and install it - or simply "relink" your file in an Office 2003 installation before shipping
Use late binding instead of early binding. In this case, you do not add a reference to the Excel library at all. Instead, you declare your objects as type Object(instead of Excel.Workbook, Excel.Application, etc.). To create a new object, instead of using Set objExcelApp = New Excel.Application, you must now use CreateObject (for new objects) or GetObject (for existing objects, e.g. an existing, running application): Set objExcelApp = CreateObject("Excel.Application"). Any later code will continue to work as usual (though it might be a tiny bit slower due to the late binding).
For further reading, check this answer.
Related
Is there a way to view the properties on SAP GUI objects?
Like this:
But for SAP objects like the following ones:
Set SAPGuiAuto = GetObject("SAPGUI")
Set App = SAPGuiAuto.GetScriptingEngine
Set Connection = App.Children(0)
Set SAPSession = Connection.Children(0)
I ask this after reading the last part of the answer to this post: VBA general way for pulling data out of SAP
If however you want to use early binding so that your VBA editor might
show the properties and methods of the objects you are using, you need
to add a reference to sapfewse.ocx in the SAP GUI installation folder.
This is something so badly advertise by the SAP team, they should definitely do a better job there.
Basically you first of all need to add a reference to the SAP object model, the libraries that VBA will understand. Don't know how familiar are you with there references to object models. Basically, on your VBA Editor, click Tools, then References, then Browse, and find this file: "C:\Program Files\SAP\FrontEnd\SAPgui\sapfewse.ocx" (or possibly "C:\Program Files (x86)\SAP\FrontEnd\SAPgui\sapfewse.ocx").
Now you'll be able to browse it on the Object Explorer (press F2 in the VBE), and declare the types.
You need now to familiarise yourself with the Types of this library. Some hints, they all start with Gui, like, GuiSession, GuiApplication, GuiConnection, GuiBlabla... Names are pretty explicit and intuitive.
To add on to what #Nelson_Vides has said. As he said, you will need to reference the sapfewse.ocx file, and you can view the class objects by pressing F2.
However, the IntelliSense will only be visible once you define an object from the SAP class library.
Dim userArea As GuiUserArea ' <-- For example
Now, whenever the object is used the IntelliSense will show up.
Best of luck and happy scripting!
SAP also provides documentation on their GUI objects:
I'm unable to create any objects in an Excel macro I am trying to write. Initially I was trying to work with MSXML2.DOMDocument60, however, I realized that i'm not able to get ActiveX to create any objects. For example, I get the same error (Run-time 429 'ActiveX component can't create object') for this line of code:
Dim ExcelSheet As Object
Set ExcelSheet = CreateObject("Excel.Sheet")
Obviously since i'm in excel, the program is installed correctly and it should have access to it. I've checked several other Stackoverflow pages for this. It doesn't appear to be an issue with a reference and I can't imagine the simple code above not working because of missing dlls since I am again already in Excel.
Is there possibly a security feature on my computer blocking this action?
Again, my issue is not with the above code. This was just a simple way to show that Create object is not working.
My main goal is to get the following to work:
Dim objXML As MSXML2.DOMDocument60
Set objXML = CreateObject("MSXML2.DOMDocument60")
I've already verified that I have the correct reference and I re-registered the Dlls.
I found the answer I was looking for. My company has the C drive and another network drive locked down, which prevents CreateObject from working when an excel sheet is saved to either of these locations. By saving the excel sheet to my desktop instead I am able to get it to work.
There's no class with an Excel.Sheet progID in the Excel object model. You probably meant Excel.Worksheet, but that won't work either, and it's not because of CreateObject or any kind of obscure security feature.
Simply put, not all classes/types are creatable: In the Excel type library Application is, and that's about it: everything else needs to be created within the object model, using the factory methods provided by that API.
In other words the only way you can create an Excel.Worksheet, is if Excel creates it for you.
Set excelSheet = Excel.Application.ActiveWorkbook.Worksheets.Add
Same with an Excel.Workbook:
Set excelBook = Excel.Application.Workbooks.Add
There are other ways (e.g. copying an existing Worksheet without specifying a Target argument will create a new Workbook that contains a copy of that source Worksheet), but rule of thumb if you can't New up a class in a referenced type library, there's little chance CreateObject can do any better (unless the type registration explicitly prevents early-binding usage).
The question was edited, but this answer stands: don't use CreateObject to create instances of classes that are already resolved and readily available.
Set objXml = New MSXML2.DOMDocument60 'works fine
If you really want to use CreateObject, then you need to use progID strings that exist in your registry.
Set objXml = CreateObject("MSXML2.DOMDocument60") ' blows up on my machine as well
Set objXml = CreateObject("MSXML2.DOMDocument") ' works fine
But using CreateObject to create an instance of a class the compiler already knows about, is a very, very roundabout way to do this.
I have recently installed visio 2010. it has VBA 7.0.
I am trying to write a code to open a file dialog, choose an excel file and open it.
I used this code
Set fd = Application.FileDialog(msoFileDialogFilePicker)
but i get the following error:
Run-time error '438':
Object doesn't support this property or method
i already have the Microsoft Office 14. Object Library as reference.
Do you have an idea? what i should do?
If you use this code in Visio
Set fd = Application.FileDialog(msoFileDialogFilePicker)
the word Application refers to Visio and as you can see in Object Browser, Visio.Application class has no such method as FileDialog. Access and Excel applications have it, but not Visio.
In order to use it in Visio you need to add reference to either Microsoft Excel Object Library or Microsoft Access Object Library. Then you need to use the code below to create an instance of FileDialog (select a proper version depending on what reference did you add to your project - Excel or Access)
'If you have reference to Microsoft Excel Object Library
Set fd = Excel.Application.FileDialog(msoFileDialogFilePicker)
or
'If you have reference to Microsoft Access Object Library
Set fd = Access.Application.FileDialog(msoFileDialogFilePicker)
Like explained by #mielk, Visio does not have the Application.FileDialog. You could use the method of Excel (in this case you'll have to have Excel installed, and started to invoke its methods) or use pure WinAPI from VBA (i.e. GetOpenFileName function). This option is explained here for example:
http://visguy.com/vgforum/index.php?topic=738.0
In an Excel 2003 VBA project I am using controls from MSCOMCTL.OCX. That is the VBA project has a reference to System32\MSCOMCTL.OCX.
When I open that project in Excel 2003 on my 64-bit Windows 7 system, Excel automatically changes the reference to SysWOW64\MSCOMCTL.OCX (which is the correct location).
However, when I send that project to my client who is using 32-bit Windows XP, the project complains during opening because SysWOW64\MSCOMCTL.OCX does not exist on his system.
Here are the (unsatisfactory) solutions I came up with so far:
Instruct the client to manually change the reference back to the correct location on his system (System32\MSCOMCTL.OCX).
This does not really work for the following reasons:
When Excel 2003 32-bit opens the sheet and it cannot find the reference to MSCOMCTL, it removes all the controls that came from the library (e. g. TreeCtrl) from the forms :-(
Client is struggling with the procedure and it is quite cumbersome for him.
Automatically correct the reference using VBA's VBProject.References.AddFromFile/AddFromGuid.
Same problem as above: When compilation of VBA during opening of workbook fails, Excel will remove all controls that it could not find from the forms.
Automatically add the reference (as in 2.) and use dynamic binding to add all the relevant controls during runtime.
This could actually work, however currently I am struggling with binding the event handlers to the controls (but that will be separate question ;-)
Approaches 1. and 2. do not really solve anything and solution 3 is a lot of work.
Any ideas would be greatly appreciated.
What if you automatically turned the reference off when the workbook closed? that way the reference wouldn't be 'broken' when the workbook is opened, and all your control should still be good.
i.e. :
Private Sub Workbook_Open()
'use environ variable for folder locs
If os = "64bit" Then
Me.VBProject.References.AddFromFile ("C:\WINDOWS\SysWOW64\MSCOMCTL.OCX")
Else
Me.VBProject.References.AddFromFile ("C:\WINDOWS\system32\MSCOMCTL.OCX")
End If
End Sub
Private Sub Workbook_BeforeClose(Cancel As Boolean)
For Each ref In Me.VBProject.References
If ref.Name = "MSComctlLib" Then
Me.VBProject.References.Remove ref
End If
Next ref
End Sub
I did a quick test with the ADODB dll and it seemed to work,but I am not sure how you're using that DLL specifically; let me know if that works, though! Sure a lot better than option 3!
I have an application that is written in Excel VBA, myApp.xls. Currently we use InstallShield to distribute the application. Since we are moving to Windows Vista, I need to be able to install the application as a standard user. This does not allow for me to update the registry during the install process. In addition to the excel application we also have several VB6 applications. In order to install those applications, I was able to use RegFree com and Make My Manifest (MMM) as suggested by people on this forum (I greatly appreciate the insight btw!). This process, although a bit tedious, worked well. I then packaged the output from MMM in a VS '05 installer project and removed the UAC prompt on the msi using msiinfo.exe. Now I am faced with installing an application that basically lives in an Excel file. I modified a manifest that MMM created for me for one of my VB6 apps and tried to run the excel file through that, but I did not have much luck. Does anybody know of a way to do this? Does RegFree com work with VBA? Any thoughts or suggestions would be much appreciated.
Thanks,
Steve
Yes, it is possible to use registration-free COM through VBA, on Win2k3+.
Fundamentally, reg-free says "this COM class no longer needs to be registered to be discoverable, instead registration info will be carried by a manifest".
Manifests themselves are implictly referenced by executables when they are embedded in the executable, or named *.exe.manifest.
However, in the case of VBA -- your code doesn't live in an executable you control, so you need another way to get a reference to the manifest.
That's where the Microsoft.Windows.ActCtx object comes in - it specifically allows you to instantiate your object given an explicit manifest reference.
For example (in JS, since I'm rusty on VBA syntax):
var actCtx = WScript.CreateObject("Microsoft.Windows.ActCtx");
actCtx.Manifest = "myregfree.manifest";
var obj = actCtx.CreateObject("MyObj");