I am curious as to what applications can be manipulated using VBA. I was under the impression that any application can be accessed with VBA by creating an object instance of the application, but I am sure there certain applications that can't.
I have the following questions:
Can any application be instantiated as object?
What would prevent an application from being able to be instantiated as an object?
An application is only controllable in VBA (via automation) if it has an appropriate Component Object Model (COM) interface.
All the Microsoft Office programs have COM interfaces, but it's not a necessary requirement for applications that run on Windows.
For further reading, see What is COM?
Related
I have a program that includes an API for automating tasks within the software. The vendor uses VBScript for their examples, but I have determined experimentally that I can write code in VB.NET to interact with the API with some caveats:
In VB.NET:
I can only create object types defined by the API using late binding (e.g. CreateObject("Type"), thus Intellisense does not work, but calls to the methods exposed by the API do work.
The application includes a .TLB file that I can reference in my project (Embed Interop Types = False), but attempts to call any methods exposed by that library give an error "This operation failed because the QueryInterface call on the COM component for this interface with IID{...} failed due to the following error: Error loading type library/DLL)
In rare instances, I find API methods that work perfectly when called from VBScript, but throw an exception when called from VB.NET (Invalid Callee).
I'm a bit out of my depth here - but can someone point me in the right direction in terms of either properly referencing/using the type library in VB.NET or explain why in the case of #3, I am having problems even using the late-binding method with VB.NET versus VBScript?
MS Word has a very useful mechanism to wrap up its dialog boxes to use via COM or .Net. You can execute a "Display" method - which does the obvious - and also an "Execute" method which is equivalent to pressing "OK". I have a legacy MFC app which I am attempting to attach a COM object model to for scripting and regression testing, and I would like to do the same thing. It has a number of dialogs that I want to control programmatically from my test harness. It's been years since I really delved into MFC, and I can't find anything useful on t'internet so far.
My guess would be to wrap up the CDialog derived classes, perhaps within an ATL class (ATL is used extensively in the project), but I have a suspicion that there may be a better way.
Worst case scenario, I'll move the dialogs to C# and make them COMVisible (which is probably more strategic), but that's going to be more work.
Any thoughts and help appreciated - obviously this is rather antiquated technology!
All CDialog derived classes in MFC are a subclass of CCmdTarget.
CCmdTarget is the baseclass for MFC COM functionality.
There is a lot of work you have to do under the hood. You should define and IDL file for your interfaces, compile the IDL, and then have the compiled typelibrary be a resource in your program.
There are helper macros for your CCmdTarget derived classes like:
DECLARE_INTERFACE_MAP()
BEGIN_INTERFACE_PART()
END_INTERFACE_PART()
BEGIN_INTERFACE_MAP()
INTERFACE_PART()
END_INTERFACE_MAP()
I would say that if you want to see how MFC does it, use the App Wizard and generate an MFC application that has OLE Automation enabled and then look at the generated code. It will show you what you need to wire up your MFC app for OLE Automation.
Either I don't understand COM objects, either it's all that confusing.
I frequently 'create' , 'dispatch' COM objects - either in Python, either in VB ( Obj = win32com.client.Dispatch('Visum.Visum') or Obj = CreateObject("Excel.Application") respectively).
That's easy, obvious and everything's fine.
But how can I:
a) connect to COM object which is already running
b) get list of running processes which are COM objects
in VB what is the reference, and additional info on: CreateObject command. In Python it's part of well defined, comprehensive library of win32com whereas in VB it's just single method without reference: http://msdn.microsoft.com/en-us/library/7t9k08y5(v=vs.80).aspx
Highly confusing (COM object,server? connection, dispatching, registering??)
Thanks for claryfying
Rafal
i2
First of all, I would suggest reading a good introduction to COM. Personally, i think that 'Essential COM' by Don Box is the best book about COM. Spending a few hours with it will save you many hours later.
That being said, let's move to your questions.
a) In order to retrieve an existing COM object from VB, you need to call GetObject function. This will only work for COM objects which are registered with Running Object Table. Excel does this, so there shouldn't be any problems with that.
b) as Hans Passant correctly noted, this question doesn't make sense. Processes and COM objects are completely unrelated things, except for the fact that processes host the COM objects. It is similar to asking 'which processes are instances of class X'. However, a process can host a COM object (or many of them). These object can be alive only temporarily, so what would you expect there? Besides, many COM classes are implemented within dlls, but created instances obviously are hosted within a process - so what would you expect there?
COM technology is something I didn't not use for a while, so sorry if some info might be wrong (anyway, I've got my book "Inside COM+ base services" with me!)
Briefly speaking, let's give a simplified definition of a COM object: it nothing else than a standard DLL with classes exposing a standard interface IUnkown with the following methods:
AddRef: to register a client consuming the COM object
Release: to unregister a client (usually unused objects stop running, but other might remain resident)
QueryInterface: to get the address of a function
QueryInterface is used to dynamically retrieve the address of a function (late-binding) which is powerful (you don't have to know the DLL at compile time) but time consuming. On the other hand, you can directly reference the addresses of the functions at compile-time because those DLL are registered in the system (all the informations are stored in the registry)
Creating a new object or getting the address of a running object is done through RPC (remote procedure call) which will load and/or play the role of a proxy
So to create a new instance of a COM object, you will call CreateObject (in VB) (Co)CreateInstance in VC++ (or even c#?), while to get an executing instance, you might want to call GetObject().
Getting the list of COM objects is not that easy (I guess not possible at all) because, as told earlier, a COM object is nothing else but a DLL: this means that the library will mainly load in the address space of each process which access is private. Even for out-process COM objects (opposite to in-process) which are object shared between many processes (i.e.: Excel is an out-of-process COM object: you don't load the DLL in your application's address space), they are loaded by a host (rpc.exe or a proprietary host)
Hope this helps
Serge
I've got a VSTO3 Word addin that makes use of custom ribbons and taskbars, etc.
Now, Office 2010 comes along and there's this nifty new BACKSTAGE concept, which I'd like to hook into. However, from what I can tell, doing it with VSTO requires Vsto 4, which requires VS2010, which isn't an option.
Soooo. I started looking online and have found all sorts of examples of, essentially, piggybacking the backstage XML onto whatever Ribbon xml I define and returning that as the value of GetCustomUI. All good, except if you're using VSTO3, there doesn't appear to be any way to "hook" into the call chain for GetCustomUI. It's all "automagically" handled for you by the OfficeRibbon and RibbonManage classes.
I know I +COULD+ convert the addin to a shared addin and just implement the IDTExtensibility interfaces directly. I'd lose all the vsto goodness (yeah, that's debatable) but I'd gain access to the GetCustomUI call.
Anyone every tried to get access to GetCustomUI +WHILE+ using VSTO though? Is it even possible?
I thought I could create a wrapper class for RibbonManager, but lo, MS has gone and done what looks to be some supreme violation of encapsulation. The RibbonManager implements the nice and easy IRibbonExtensibility interface, and yet, where that interface is passed around, they actually check the passed object to be sure it's of the actual type RibbonManager! Ugh, so much for any kind of wrapper.
Turns out it's possible, just not easy. You have to override the CreateRibbonExtensibilityObject method on connect, as well as the CreateRibbonObjects, and the RequestService methods.
Then, you have to create an object that wraps the built in VSTO RibbonManager object, and implements iReflect to intercept reflection INVOKE calls and forward them on to the underlying RibbonManager.
Finally, on the interceptor object, you have to also implement IRibbonExtensibility, then code up the GetCustomUI method of that interface.
once you do all that, your GetCustomUI will be called and passed in the full XML of the ribbons you've defined via VSTO, which you can then alter directly (in my case I needed to add backstage support), and then return that xml from the function.
definitely not straightforward, but it works.
If you want to edit XML ribbon at runtime in a VSTO app, I have created a simple solution here: Outlook 2007 ribbon customization in .NET using VS2010; insertBeforeMso dynamic function
I searched hard, but was unable to grasp the whole idea. Can anyone tell me:
What COM actually is?
How do GUIDs work, and how are they used by COM?
How does COM resolve the issues of different DLL versions.
Or at least, point me to a good article somewhere that explains these concepts?
Thanks!
COM is "Component Object Model". It is one of the first technologies designed to allow "binary reuse" of components... Originally, it was the rewrite of what was, in Microsoft Office circa 1988-1992 time frame, referred to as Dynamic Data Exchange (DDE), a technology designed to allow the various Office applications to talk to one another. The first attempt to rewrite it was called OLE-Automation (Object Linking and Embedding). But when they got done they renamed it to COM.
How it works:
Essentially, before COM, when a client component wanted to use a component (written as a C++ library), it had to be compiled WITH the library, so it could know exactly how many bytes into the compiled binary file to find each method or function call.
With COM, there is a defined mechanism as to how these methods will be structured, and then the compiler produces a separate file (called a type library or an Interface Definition Language (IDL) file, that contains all this function offset data.
Then, as a user of the component, you have to "register" it, which writes all this information (Keyed off of GUIDs) into the OS Registry, where any client app can access it, and by reading the data from the registry, it can know where in the binary file to find each method or class entry point.
Your question is a little large for a full explanation here. A quick high-level introduction to COM can be found in the book Understanding ActiveX and OLE. A more detailed but still introductory introduction is Inside COM. The best book on the subject is Don Box's Essential COM.
A couple of quick answers:
COM is a binary interface standard for objects. It allows various programs to write to interfaces without all having to have been written in the same langauge with the same compiler. There are also related services available.
GUIDs are globally unique numbers that COM uses to identify interfaces.
COM doesn't resolve different DLL version problems. It only allows a single DLL to be registered for each GUID.
COM enables reusable software. Like building blocks, you can create COM objects (or now Assemblies in .NET) to provide functionality to a larger piece of software. I have used COM to provide DB integration for Excel and MS BizTalk. Software like MS BizTalk use COM/Assemblies to extend the processing capabilities of a standard process; you can insert a COM into the message workflow to do more processing than is implemented by Microsoft. COM also allows use of Component Services providing built in object pooling, security, and control interface.
Wikipedia has a good definition of GUID. Note that Microsoft has a formatting that is not necessarly used in the rest of development community.
COM by itself does not resolve DLL version issues. It enables you to extend software incrementally if you use the COM versioning capability. So if you have an application that uses a COM to convert XML to Text (for example) and you want to enhance, you can create a new version (2.0) which you can roll-out slowly as you update the source application to use the new COM. This way you could (if need be) have a switch statement that can still use the old COM if required by system limitations, or use the new one (they would be different DLLs).
COM is a lot of different things. I recommend Don Box's book, Essential COM as a good way to learn.
At a bare minimum, a COM object is an object that exposes a single interface, IUnknown. This interface has 3 methods, AddRef, Release, and QueryInterface. AddRef/Release enables the object to be reference counted, and automatically deleted when the last reference is released. QueryInterface allows you to interrogate the object for other interfaces it supports.
Most COM objects are discoverable. They are registered in the registry under HKEY_CLASSES_ROOT with an identifying GUID, called a CLSID (class ID). This enables you to call CoCreateInstance to create an instance of a registered object if you know a GUID. You can also query the registry via a COM API for the CLSID that backs a ProgId (program id), which is a string that identifies the object.
Many COM objects have typelibs that specify the interfaces and methods the object supports, as well as IDispatch which has a method, Invoke, that allows you to dynamically call methods on the object. This enables the object to be used from scripting languages that don't support strong typing.
Some objects support being run in a different process, on a different thread, or on a different machine. COM supports marshalling for these types of objects. If possible, a standard marshaller can use the object's typelib to marshal calls to the object, but custom marshallers can be provided as well.
And there's a whole lot more to COM objects, I'm barely scratching the surface.
10,000 foot view:
COM is the communication mechanism for software components. Example, you can interact with COM interfaces (COM interop in .NET) to use functionality not exposed through a common interface (.NET assembly).
GUIDs are explained fairly decent on Wikipedia http://en.wikipedia.org/wiki/Globally_Unique_Identifier
I always understood LIB files to be object files for the C++ linker. They contain the code for all objects in a cpp file. The compiler optimizes when it links disregarding portions of the object file that it doesn't need.
Someone please clarify as I am sure I butchered some of this.
COM is Microsoft's Component Object Model, a binary-compatible interface for programs written in various languages to interoperate with each other. It is the "evolutionary step" between the OLE and .NET technologies.
If you want to learn about COM from the C++ perspective, take a look at Don Box's Essential COM, or ATL Internals by Rector and Sells.
The group microsoft.public.vc.atl is probably the best place to ask questions you can't get answers for here. It's primarily an ATL newsgroup, but it seems to be the newsgroup with the most traffic for general COM questions as well. (just be prepared for the usual newsgroup curtness & impatience)
COM is a method to develop software components, small binary exe, that provides services for applications, OS and other components. Developing custom COM comnponent is like developing Object oriented API. GUID is a Global unique ID and used to identify a COM component uniquely.
You can refer a very good book by Dale Rogerson for more details. Inside COM