I usually create an Excel (or ppt) object like:
Imports Microsoft.Office.Interop
Private _xlApp as Excel.Application
_xlApp = CType(GetObject(, "Excel.Application"), Excel.Application)
...
now checking something on msdn I saw in an example they are doing it this way:
Imports Excel = Microsoft.Officee.Interop.Excel
Dim xlApp as Excel.Application = Nothing
xlApp = New Excel.Application
Could anyone explain the difference between these two methods since I want to apply it right and cannot see the differences.
in the first case, you're just getting a COM object by name and casting it to its own Type. really only useful to instance objects from a file library which isn't registered for COM interop, or to get some other object from a file. i suppose you can also use it to get the instance of a running application.
hmm, it seems you can load excel files as objects directly from file: http://msdn.microsoft.com/en-us/library/e9waz863%28v=vs.90%29.aspx
in the second case, you're just referencing the managed interop library and creating the object directly. http://msdn.microsoft.com/en-us/library/aax7sdch%28v=vs.110%29.aspx
Related
Consider the following code:
Public Sub VBACompilerIsMad()
Dim Ap As Application
Dim Wb As Workbook
Dim Ws As Worksheet
Debug.Print Ap.XXX ' No compile error
Debug.Print Wb.XXX ' No compile error
Debug.Print Ws.XXX ' Compile error
End Sub
When I compile this, I get a compiler error for referring to an inexisting member of Worksheet. However, if I comment out the last line, there is no compiler error, even though neither Application nor Workbook have a method or property XXX. It is as if I declared Ap and Wb as Object variables.
Why does the compiler treat Application / Workbook differently from Worksheet?
Are there any other classes like this, that the compiler seems to treat as if they were Object?
As I have been explained (kudos go respectively), this is a COM feature.
By default COM assumes an interface is extensible, that is, it allows adding members at run time. If that is not the desired behaviour, one can apply the [nonextensible] attribute to the interface definition, which declares the interface only accepts methods explicitly defined in the type library.
dispinterface _Application and dispinterface _Workbook do not have this flag set in the Excel type library, dispinterface _Worksheet does.
Similarly, ADO's dispinterface _Connection does not have [nonextensible], dispinterface _Command does.
To learn which are extensible, add a reference to TypeLib Info in the project's References and run:
Dim t As tli.TLIApplication
Set t = New tli.TLIApplication
Dim ti As tli.TypeLibInfo
Set ti = t.TypeLibInfoFromFile("excel.exe")
Dim i As tli.InterfaceInfo
For Each i In ti.Interfaces
If (i.AttributeMask And tli.TYPEFLAG_FNONEXTENSIBLE) <> tli.TYPEFLAG_FNONEXTENSIBLE Then
Debug.Print i.Name
End If
Next
You will see that almost all interfaces are extensible here, so most of them get pushed out of the debug window and you will only see the last ones. Change the <> to = to print those that are not extensible, there are much less of them.
A bit of a hypothesis:
You can call a stored procedure on an ADODB.Connection object like a native method (at the bottom).
(The examples for this on several msdn sites look oddly messed up).
So there is some mechanism like 'anonymous/dynamic methods' in VBS/VBA.
It may be a similar mechanism activated here for Application and Workbook classes - although I don't see where and how exactly.
A test supports the basic idea:
I have tested this with a reference to Microsoft ActiveX Data Objects 2.8 Library:
Public Sub testCompiler()
Dim cn As ADODB.Connection
Dim cmd As ADODB.Command
Debug.Print cn.XXX
Debug.Print cmd.XXX
End Sub
cn.XXX does not throw a compile error, cmd.XXX does.
GSerg's answer is indeed outstanding, I love the whole COM type library IDL and how some attributes there can govern the behaviour in the Excel VBA IDE. Long may this arcane knowledge of COM be handed down! And, I realise this question has been bountied to give that answer more rep but when a bounty is set it appears on my radar and I have a view on this matter.
So although GSerg's answer gives the mechanism it does not give the rationale, i.e. it gives the how but not the why. I'll attempt to answer the why.
Some of the answer why is already given by Martin Roller (OP) in his comments about Application and WorksheetFunction. This, to me, is a convincing reason to keep Application extensible and I'll not consider Application further.
Let us turn to Workbook and Worksheet and we best start with some code to demonstrate, so you will need to begin with two fresh workbooks, call them MyWorkbook.xlsm and OtherWorkbook.xlsm. So some instructions:
In OtherWorkbook.xlsm go the code module ThisWorkbook and paste the code
Option Explicit
Public Function SomeFunctionExportedOffOtherWorkbook() As String
SomeFunctionExportedOffOtherWorkbook = "Hello Matt's Mug!"
End Function
In MyWorkbook.xlsm go the Sheet1 code module and paste the code
Option Explicit
Public Function SomeFunctionExportedOffCodeBehindSheet1() As String
SomeFunctionExportedOffCodeBehindSheet1 = "Hello Martin Roller!"
End Function
Now, in the VBA IDE change the codename of Sheet1 to codebehindSheet1
Now, in a new standard module in MyWorkbook.xlsm add the following code
Sub TestingObjectLikeInterfacesOfWorkbookAndCodeBehindWorksheet_RunMany()
'* For this example please rename the 'CodeName' for Sheet1 to be "codebehindSheet1" using the IDE
Debug.Assert ThisWorkbook.Worksheets.Item("Sheet1").CodeName = "codebehindSheet1"
Dim wb As Workbook
Set wb = Application.Workbooks.Item("OtherWorkbook")
'* Workbook dispinterface needs to not marked with nonextensible attribute
'* so that it doesn't trip up over exported function in another workbook
'* below SomeFunctionExportedOffOtherWorkbook is defined in the ThisWorkbook module of the workbook "OtherWorkbook.xlsm"
Debug.Print wb.SomeFunctionExportedOffOtherWorkbook
'*Not allowed --> Dim foo As Sheet1
'*have to call by the 'code behind' name which is usually Sheet1 but which we changed to illustrate the point
Debug.Print codebehindSheet1.SomeFunctionExportedOffCodeBehindSheet1
End Sub
Now run this code above.
You've probably read the code and hopefully understood the point I'm making but let me spell it out. We need Workbook to remain extensible because it may contain a reference to another workbook which may be exporting a method or function and we'd like no compile errors.
However, for the Worksheet, to do a similar export we again add code to the code behind module but there is a difference in referencing the module: one grabs a reference to that code behind module by using its VBA code name, most people do not change this from Sheet1 (that is why you were invited to change it above).
So the interface obtained by the code behind module name needs to extensible and not the Excel.Worksheet interface.
P.S. Anyone got a copy of TLI.dll?
As a workaround it could still be possible to create your own interface and implement this interface. Then declare a variable as INewInterface and all the compiler messages will be there :). Here simple example with custom interface for a UserForm. HTH
Interface
Public CancelButton As MSForms.CommandButton
Public DataList As MSForms.ListBox
Public CommandBox As MSForms.TextBox
Implementation
Implements IMyForm
Private Property Set IMyForm_CancelButton(ByVal RHS As MSForms.ICommandButton)
End Property
Private Property Get IMyForm_CancelButton() As MSForms.ICommandButton
End Property
Private Property Set IMyForm_CommandBox(ByVal RHS As MSForms.IMdcText)
End Property
Private Property Get IMyForm_CommandBox() As MSForms.IMdcText
End Property
Private Property Set IMyForm_DataList(ByVal RHS As MSForms.IMdcList)
End Property
Private Property Get IMyForm_DataList() As MSForms.IMdcList
End Property
Usage
Note: MyForm is existing VBA Form which has been added to the project.
I have implemented several basic Excel functions in my vb.net application (opening an xls workbook & accessing worksheet). However, it appears that when I add the Reference "Microsoft Excel 14.0 Object Library" the application is getting confused with the standard System.Windows.Forms objects and has the following error: InvalidCastException occured: Unable to cast object of type 'System.Windows.Forms.TextBox' to type 'Microsoft.Office.Interop.Excel.TextBox'. The Invalid Cast error is happening when calling a subroutine & passing the application form controls (check boxes, GridView, TextBox, etc) from my main "Form1" class into a UtilityFunction module. UtilityFunction has a reusable Windows Registry sub routine which retrieves/saves values at application startup/closing. This worked in the past, but now is crashing at the subroutine call in the Form1 class. The exception occurs during application runtime, not during the compile/build.
Also, I deleted the text controls from the form and created them manually, but I'm still getting the same exception error.
When you have a Namespace conflict you need to fully qualify the object you want.
Dim excelTb As New Microsoft.Office.Interop.Excel.TextBox
Dim formTb As New System.Windows.Forms.TextBox
I solved this problem by using the following code:
Imports X = Microsoft.Office.Interop.Excel
Dim xlApp As X.Application = New X.Application
In Excel, I have a VBA module called MyModule which has a function as such
Public Function MyFunction(Param1 As Range, Param2 As Range) As String
' some implementation
End Function
At runtime, I know that I have a module called MyModule and I know I have a function called MyFunction but I want to inspect dynamically the parameter names Param1 and Param2
In my world (C#), this is called reflection. Can I use similar concepts here to get the parameter name or am I expecting too much from VBA?
There is a good analysis at this CodeProject http://www.codeproject.com/Articles/164036/Reflection-in-VBA-a-CreateObject-function-for-VBA
Extract:
VBA does not support reflection, an OOP concept which has many
facets, including the ability to instantiate a class without knowing
its type at design time. Reflection offers great flexibility that is
agonizingly absent from VBA (at least for those of us who like to use
VBA for more than it is typically intended).
There are some reflection-like things possible:
Example
For example, if I wanted to create an instance of an Excel Application object without having to declare the type explicitly in code (using Set xlApp = New Excel.Application), I can do so using the following reflection-level object creation code:
Dim xlApp As Excel.Application
Set xlApp = CreateObject(,"Excel.Application")
This is the equivalent of the type specific statement
Set xlApp = New Excel.Application
Also:
You can use assylias approach to interrogate your own code (using regexp or some other parsing to pick out the parts of your code you are interested in):
yourWorkbook.VBProject.VBComponents("MyModule").CodeModule
There are some interesting leads in this post: Iterating through the Object Browser in VBA
I like to use early binding in my VBA projects, since I like the auto-complete of method names, etc. during development. I also like the confidence of knowing that the compiler will warn me if I've mis-spelled a method name.
However, to use early binding I need to add a reference to the relevant library (for example, the "Microsoft Scripting Runtime"). That's fine for "standard" libraries like that, but sometimes I want to use a library that may or may not be present on the user's machine.
Ideally, I'd like to display a useful message if the library is not present (such as "xyz is not installed on this computer, and so this feature cannot be used"). If I was using only late binding, then I could do this:
Dim o As Object
Set o = CreateObject("foo", "bar")
If o Is Nothing Then
MsgBox "nope"
End If
But, if I've added a reference to the library in order to use early binding, then if the library is not present I get a compile error when my VBA project is loaded. Thus, none of the code runs (including the code to detect the non-existence of the library).
Is there any way around this catch-22?
You could create a class module as a proxy for an object library --- wrap all the methods, properties, and constants needed by your other procedures.
All those procedures would use the proxy class the same way, so you wouldn't need to revise those procedures to switch between early and late binding. And Intellisense would show you everything you expose with the proxy class.
The class would be a single point of control to switch between early and late binding. You mentioned Excel as one example:
#Const DevStatus = "PROD"
#If DevStatus = "DEV" Then
Private objApp As Excel.Application
Private objBook As Excel.Workbook
Private objSheet As Excel.Worksheet
#Else 'assume PROD
Private objApp As Object
Private objBook As Object
Private objSheet As Object
#End If
If there is a possibility Excel may not be installed on any users' machines, you can check its availability during class initialize.
Dim blnExcelAvailable As Boolean
Private Sub Class_Initialize()
blnExcelAvailable = IsExcelAvailable()
End Sub
Private Function IsExcelAvailable() As Boolean
Dim blnReturn As Boolean
Dim objTest As Object
On Error GoTo ErrorHandler
Set objTest = CreateObject("Excel.Application")
blnReturn = True
ExitHere:
On Error GoTo 0
Set objTest = Nothing
IsExcelAvailable = blnReturn
Exit Function
ErrorHandler:
blnReturn = False
GoTo ExitHere
End Function
Then your procedures which use the proxy class could check a property to see whether Excel is available.
Public Property Get ExcelAvailable() As Boolean
ExcelAvailable = blnExcelAvailable
End Property
I think this approach is possible, and it satisfies your requirements AFAICT. However, I'm unsure whether it's reasonable. Back to the example of Excel, you could do something like this for a manageable subset of its object model. But if you need all or most of its methods, properties, and constants, the proxy class would be a huge undertaking.
Personally I wouldn't use this approach. It's less work for me to manage early/late binding as mwolfe02 and JP. described. However my impression is this is more burdensome in your situation, so perhaps you're willing to invest more effort than I am in something like this.
Not really.
However, one way I've dealt with this in development is to have two separate declaration lines. I comment one or the other depending on whether I am doing dev work or releasing to production. You can leave everything else alone (including the CreateObject line) and then you just need to remember to switch the commented line and add/remove the reference itself.
For example:
Dim o As foo.bar 'Comment out for production'
'Dim o As Object ''Comment out for dev work'
Set o = CreateObject("foo", "bar")
If o Is Nothing Then
MsgBox "nope"
End If
please help me on creating a user control object in runtime using createobject function or whatever better function in vb.net.
here is my code:
Dim b As New Security.Sec_Role
b.Name = "Sec_Role"
b.visible = true
but i want to use this code:
dim b as object
b = createobject("Security.Sec_Role")
but it always return an error:
Cannot create ActiveX component.
EDIT: i figure it out..thanks a lot..i use this codes:
Dim asm As System.Reflection.Assembly = Assembly.Load("Security")
Dim b As Object = Activator.CreateInstance(asm.GetType("Security.Sec_Role"))
If it is an .Net UserControl you will not be able to use CreateObject unless it has been exposed as a Com object according to the MSDN page for CreateObject. Using New would be the proper way to create a .Net UserControl.
From above link:
Creates and returns a reference to a COM object. CreateObject cannot
be used to create instances of classes in Visual Basic unless those
classes are explicitly exposed as COM components.
From this MSDN Forum try something like this using System.Activator.CreateInstance:
Dim oType As System.Type = Type.GetType("MyNamespace.ClassName")
Dim obj = System.Activator.CreateInstance(oType)
.Net classes are not ActiveX controls.
You can't do that.
You may be looking for Reflection or a dictionary.
You will want to use Activator.CreateInstance:
Dim b as object
b = Activator.CreateInstance(Nothing, "Sec_Role")
It will be easiest if this method is in the assembly which has the controls. Otherwise, you will need to provide the assembly name in the first parameter.