_.....Continued from last post….

Dealing with objects when programming the VB Editor

Something going by the name of Automation Object Linking and Embedding, or Automation OLE or Automation is part of some very fundamental software things going way back that Microsoft did: It is especially good apparently at making it possible to run some application in others.

There are two ways to use Automation to programmatically control another application. These are referred to as Early Binding or Late Binding

For Early Binding you need to set a reference in your project to the application you want to manipulate. However this does not necessarily mean that you can manipulate the application.
Possibly then , ( I suggest, I don't know for sure) , that to set a reference does not always mean that you have Early Binding.

( The advantages we have discussed of using Early Binding rather than Late Binding are:
_ Access to the application's built-in constants
_ Ability to declare to the object types of the application leading to
____Intellisense
____Syntax checking at Compile
_ There maybe some minor efficiencies to do with how the computer handles Early Binding compared to Late Binding
_ You may have access to the application's object model via the Object Browser and VBA Help
)

If you are attempting to access the Class of some application, then that could well mean that you are trying to programmatically control another application. In other words you want to do Automation . In oher words you need to do Binding.

Then to do this, for the Early Binding case you would tend to
_(i) check the reference,
_(ii) Dim a variable to the objects Class
_(iii) then you need to Instantiate an instance using the class ( you could argue that _(i) and / or _(ii) is the first part of this )
To Instantiate you can
either
__ use the New stuff in your Set line
or
__ use the CreateObject("….","…. ") thingy in your Set line
( The Diming step in _(ii) could be regarded as meaning that you are Early Binding. I would suggest that that is debatable. )

For Late Binding you only have the possibility to use the CreateObject("….","…. ") thingy in your Set line, and as you do not have the object types available to Dim. You must Dim As Object

If you try either of those Binding ways in the case of the VBIDE being discussed in this Thread, then they will fail. The short answer to why that is, is that Microsoft do not allow Automation in this case. The in depth explanation of this is galaxies beyond my level of computer understanding, but it is something like the Component Object Model used by Microsoft to allow this Automation is not "exposed"
A common circumstance for Microsoft to do this forbidding is when something is dependant on something else for its existence, as is the case of the things to do with the VB Editor

My conclusion is that Late Binding, and possibly Early Binding also, is not possible in for VBIDE

We can do, ( as far as I can tell all ) the same programming in the VB Editor with or without a reference to Microsoft Visual Basic for Applications Extensibility 5.3, ( Class Name: VBIDE ) . In other words .. We can do, ( as far as I can tell all ), the same programming in the VB Editor with or without "Object" as the Dim )
( If we check the reference then we can Dim to an object type from VBIDE, and have the advantages mentioned above. )

For all day use in most situations other than ones like the VBIDE, this would do as an alternative, definition:

Alternative View Point ( http://eileenslounge.com/viewtopic.p...art=40#p246593 ** )
Dim x As _....
_Set x As _....


Late Binding: things like cannot use IntelliSense with x , x is an object , (cannot you check the syntax for x)

Early Binding: things like can use IntelliSense and syntax checking for x. x is an application object

If you wish to extend this to cover the VBIDE, then :

Set a reference to Microsoft Visual Basic for Application Extensibility 5.3
Dim x As VBIDE.CodeModule
_Set x = ThisWorkbook.VBProject.VBComponents("ThisWorkbook").CodeModule
__This is early binding, since x is a VBIDE.CodeModule object. You can use IntelliSense and syntax checking for x.

Set a reference to Microsoft Visual Basic for Application Extensibility 5.3
Dim x As Object
_ Set x = ThisWorkbook.VBProject.VBComponents("ThisWorkbook").CodeModule
__Although you set a reference to the VBIDE object library, this is late binding, since x is a generic object. You cannot use IntelliSense with x, nor can you check the syntax for x.

Do NOT set a reference to Microsoft Visual Basic for Application Extensibility 5.3
Dim x As Object
_Set x = ThisWorkbook.VBProject.VBComponents("ThisWorkbook").CodeModule
__Late binding. You cannot use IntelliSense with x, nor can you check the syntax for x.







Ref:
' https://www.excelforum.com/excel-pro...fers-it-4.html
' https://www.excelforum.com/excel-pro...ml#post4384945
' https://www.excelforum.com/excel-pro...offers-it.html
' Generally for Objects where there is dependency, that is to say....... they cannot exist independently and / or there are other Objects which are affected by the existence of such Objects..... , you will not be allowed to make a New Instance. Instancing by the user directly will not be allowed. This is likely because there will be some very complicated "Wiring" involved. There will need to be information given, for example, as "where should it go", as other Objects may be effected. So those things are best left to a Function or Method, ( a .Add or .Insert , for example ). There will always be arguments associated and require them ( if you ,leave them about, VBA at compile will try to guess ( based on other available information and / or arguments), what you want, or always using a particular default when you omit an argument )
' Book: VBA for the VBE, Lisa Green. thinkz1.com
' http://www.eileenslounge.com/viewtop...246518#p246518
' HansV eileenslounge.com **