I can't wrap my head around the differences among these terms.
Are COM and ActiveX synonyms?
Is ActiveX object just a COM object that exposes IDispatch?
Lots of older MSDN pages mention IDispatch without any COM context. Does it have a separate history, and was just introduced under the COM 'umbrella' later in its lifecycle?
Where does OLE fit in? Is its (considerable) presence in MFC naming and MSDN in general - all just legacy?
Wikipedia gives some insight, but not much. I couldn't find a more in depth reference.
Found some quotes from COM Programming by Example:
Another thing you'll quickly find with
COM is that marketing had a field trip
day with the terminology. Rather then
helping to promote understanding,
you'll find in most cases it promotes
mystery. ... OLE, ActiveX, Remotable
Objects - which one means what this
week? ...
COM evolved out of the solution to a
specific problem - how to allow a word
processor to edit the spreadsheet in a
letter without the user having to exit
the word processor to do it. This
solution was called OLE. ... However,
with the second release of OLE (OLE2),
its creators modified OLE32.DLL to
expose more of the basic functionality
of OLE so that its API could be used
to allow any application to acess the
functionality of another. This API,
which hasn't changed much since 1993,
is what is considered to be the COM
API.
...
Once the COM API was exposed,
Microsoft used it to create what were
then called OLE controls to allow
sophisticated controls (e.g., buttons
that spiral, list boxes that play
music) written in Visual C++ to be
accessible to Visual Basic
applications. Eventually this same
technology was used to allow a control
to be downloaded and used by your web
browser. At this point, the name
changed to ActiveX controls or just
plain ActiveX purely for marketing
reasons. Although you can package any
functionality in an ActiveX Control,
its requrirements have been
specialized for supporting a user
interface control.
I'm still curious about the very last sentence - must a COM object satisfy some additional requirements to qualify as an ActiveX control? - but its enough to let it go.
Thanks for your answers!
ActiveX is marketing-ese for COM, although ActiveX is usually used in the context of "ActiveX controls" which are GUI objects.
IDispatch is an interface implemented by COM objects so that client programs can call its methods dynamically at run-time (late-binding), as opposed to at compile time where all the methods and argument types need to be known ahead of time.
OLE is the earlier version of COM.
Regarding OLE: COM has its roots in OLE. But today, OLE may be considered to be built on top of COM and is mostly used for what its name suggests -- document linking and embedding. While COM itself defines only a couple of interfaces itself (IUnknown, IClassFactory, IMalloc etc), OLE adds a whole bunch of additional interfaces like IMoniker, IOleItemComtainer, etc.
To sum up: COM is the foundation, ActiveX and OLE are layers on top of COM.
Related
I was searching MSDN and several other Access forums for creating custom Access API's, but didn't see anything related. Is this possible? Can custom ODBC's be created for Access?
Hum, this is confusing since it not clear if you are talking about building interfaces with Access to OTHER systems, or are you talking about a building an Access interface that other programs can use?
ODBC is a "driver" provided by vendors to allow use of their SQL database systems and is something that you don't create in Access or FoxPro or in VB for that matter. In fact I can't think of any data centric tool that would allow you to build your own ODBC driver. So this suggests some confusing here.
Extending Access.
Access for the last 20 years has had the ability to consume ActiveX (COM objects). So how one extends the ability of Access to communicate with other software and systems REMAINS the COM object choice. So for example one can use the MSXML library from Access (a COM object) and this allows one to consume web pages, and specify XML which opens the door to consuming web services. In fact I used MSXML to consume SharePoint web services for example.
However for consuming web services it is usually far better to build COM object with tools that can "already" consume web services. So one would use vb.net to create a COM object and THEN reference that COM object from MS Access (so just like we set a reference to outlook or word from Access, such COM objects are not limited to applications you purchase, but you are most free to create your own COM objects VB6, vb.net, c# or whatever).
Access does NOT have the ability to create ActiveX (com objects), but it certainly can consume ones you build in other languages.
NOTE: I am using the term ActiveX and "COM object" interchangeability here – they are the same basic technology.
So if you ever used a desktop computer and any windows development tool, you find that "COM" objects are the choice and REMAIN the choice of how to extend Access, or even that of VB6. With managed code, things change somewhat, but vb.net is quite happy to create COM objects that work well with Access.
While Access cannot as a tool create ActiveX (com) objects, you can certainly compile Access code into an accDE and THEN reference that library code from the VBA tools->references. So you can extend and share VBA code in one library with "many" applications, but this is not a com object.
So just like in the past to extend desktop programs, you can build such extensions as COM objects and consume them from Access – this is the standard approach to extend Access to say consume web services.
Access cannot be used to build individual COM objects as UI parts, but the STANDARD means in our industry to create COM objects is able to be consumed by Access.
Last but not least:
Any application you build in Access CAN BE CONSUMED as a COM object by other applications. So while you cannot build individual COM objects, your WHOLE application is in fact a com object.
So if you build an Application in Access then using Excel, VB6, FoxPro, another Access application, C++, or C# or vb.net? They ALL CAN consume your application as a com object by simply creating an instance of Access and your application.
So any development tool that supports "com" can consume your application as a com object. So any standard development tool, article or system for the last 20 years can consume your Access application as a COM object.
So while Access cannot create individual COM objects, the resulting Access applications are in fact a legal com objects that ANY application that supports COM can create an instance of your application. This means your code and VBA subruties etc. are callable from the host application that created the instance of your application. In theory any VBA code exposed as "public code" are thus able to be called from that other program.
So the "interfaces" available to Access remain the SAME as the near 20 year history of MOST desktop programs running on windows – that interface is COM.
So you have 20 years of history and 20 years of examples on the internet to have fun with - any example that shows how to create and consume a com object should work for your access application.
I understand that COM is really a way to program (i.e. like structured programming, or OO programming). However it is a little old. So I was just wondering what has really replaced this set of specifications? Will I find this in .NET documentation?
COM has not been replaced. The Component Object Model is a core part of Windows and will remain so for the foreseeable future.
COM provides you with one mechanism of inter process communication (communicating between applications on a machine), it is also used as a much simpler (for the consumer) system of sharing dlls. Its COM (or ActiveX, or OLE - all the same) that enables VBA to work so well in MS Office, it is the foundation of ActiveX controls.
COM is not a way to program (unlike OOP etc) it is a technology that works on windows to make access to other applications during runtime easier.
.NET can use COM object with wrappers, and if you want to allow any app to access your functionality, its still best to provide a COM wrapper.
Other methods of inter app coms now exist such as ZeroMQ.
The original specification for COM is old in age, but the specification as well as the concepts are still in use, and you can still create and consume COM objects.
For .NET, you can start by looking at the following links:
Com Interop Part 1: C# Client Tutorial (C#) # MSDN
Interoperating with unmanaged code # MSDN
In addition, there are other specs that are very similar to COM or have semantics that are the same. Most notably, XPCOM is in use in FireFox for their plugin spec and also used internally to FireFox to connectable objects.
XPCOM # MDN (Mozilla)
WinRT is an upcoming platform update for windows that is also heavy in COM concepts.
There are some useful here: Why is WinRT unmanaged # StackOverflow
For .NET developers, a lot of the declarative overhead is hidden as mentioned here: WinRT demystified - Miguel de Icaza
The head of the spec is here: The Windows Runtime # MSDN
And in the context of COM, developing WinRT components with C++ has similarities, although some syntax is borrowed from managed C++: Creating Windows Runtime Components in C++ # MSDN
Visual C++. I have to implement some drawing and printing functionality that will be incorporated into (other developers') COM dll. Firstly I thought of doing everything using pure GDI and nothing more, but it seems that printing and print previewing is hell of a job to be done in GDI compared to the MFC implementation. So I decided to focus on MFC. Quick side question here: Is my choice right? I mean, are any easy ways of implementing printing (and print-preview) without MFC?
Now that I need MFC (assuming if you also agree with this), I have two questions about how to do it:
1) I believe the COM dll is the ATL project (it's not my code, some other developers independently develop it). Can I enable MFC support in that dll? What are the risks/limitations/drawbacks of having MFC runtime in the COM server? And if you advice doing this, how can I do it?
2) As much as I want to affect the third-party COM server's code as little as possible, I thought it might be the better approach to implement my code as a separate MFC-based DLL, and load and use that DLL from COM server. Do you advice doing this? What are the risks/limitations/drawbacks in this situation?
Shortly, I want to use MFC's drawing and especially printing capabilities in my code, which itself should be integrated in another developers' COM dll (which itself is utilized in a large corporate application). I'm no expert in COM technology so I'm a little bit confused. What are my best options?
You can use MFC in your own dll internally, and expose functionality to your users with non MFC intruded function: for example if you need to pass a point from/to ypur caller, use the GDI standard POINT structure, then convert it to a CPoint to use internally. In this case you don't need to enamble use of MFC in the ATL project ( that is possible anyway ) but of course you need to distribute or link with the MFC dll. If you want mantain the caller com dll as clean as possible, you can definitely create your own ATL+MFC dll and expose your functions via com interfaces too, but keep in mynd to avoid put MFC related objects in the interface.
Printing and print preview is a hell of a job unless you're using MFC Document/View Architecture. Will your COM expose such advanced UI?
If your COM must be independent of .NET then MFC is the way to go, otherwise I would use .NET. If you choose MFC, make sure you link to it statically. Otherwise you will most likely end up with runtime errors on machines where the necessary MFC version is missing.
Except for this, I wouldn't worry about compatibility since the idea of COM is to let the underlying magic do the marshaling of integers, strings and other objects.
What is an OLE Automation object: wikipedia says:
is an inter-process communication
mechanism based on Component Object
Model (COM) that was intended for use
by scripting languages – originally
Visual Basic – but now are used by
languages run on Windows.[3] It
provides an infrastructure whereby
applications called automation
controllers can access and manipulate
(i.e. set properties off or call
methods on) shared automation objects
that are exported by other
applications. It supersedes Dynamic
Data Exchange (DDE), an older
mechanism for applications to control
one another.[4] As with DDE, in OLE
Automation the automation controller
is the "client" and the application
exporting the automation objects is
the "server".
My question is:
Is it possible to use a C# code, (seems only C++) (wich uses several other C# includes) and call a them in a Stored Proc.
Is it possible to read a table with these Object?
Is it possible to compute things with that object, with table data?
What would be the steps?
Well, if you're using MS SQL Server 2005 or later, you can set up what's called a "CLR Stored Procedure", basically written in C# and able to reference other .NET assemblies. This would remove any need to refer to a .NET assembly using COM. More info: http://msdn.microsoft.com/en-us/library/ms131094.aspx
AFAIK, COM's COM; the idea is that messages are passed at the OS level between the client code and server control, and the client doesn't have to know any specifics of the server implementation; just the "front door" interface. So, if you had to use COM, you should just be able to register your .NET assemblies for COM (the main change is just a switch in the Build tab of the project's Properties view in VS), and then use them as if they had been written in C/C++, VB, Delphi, or whatever.
I have some MFC code (custom CWnd controls and some classes to expose) that I need to make into an activex / COM object with interfaces. Is it easier to make an ATL project with MFC support and make my ActiveX that way or make an MFC ActiveX control?
When doing an activeX control, is doing dual interfaces (like that explained in ACDual from microsoft) good/bad/makes no difference?
MFC is an easier route if you're a newbie in COM stuff: The wizards are better and more helpful. But it's far less flexible than ATL, which is probably not an issue if you simply have a couple of simpole interfaces to implement.
Also, IIRC MFC doesn't support dual interfaces. Dual interfaces are interesting in 2 cases:
- Performance is an issue. Such as a call to a short method executed millions of times.
- The object users are programmed in C++. Calling a native interface is way easier in C++ than calling an automation interface.
In conclusion, dual interfaces are cool but they are really interesting only if you can have them for free. Which means you use a framework which supports them. If you plan on much COM-based work, it's interesting to investigate in ATL and deeper COM knowledge. If you just have to provide a couple of simple MFC-based objects, just stick to MFC.
It's a bit of pain to use MFC for COM - there is too much code to write, macros to copy -
however you have to know what you're doing if you are mixing MFC and ATL because they are deceptively similar yet different, especially if you create windows with ATL.
The main thing is, if you use MFC from an ATL, you will need to start every one of your ATL method with AFX_MANAGE_STATE(AfxGetStaticModuleState( )), otherwise you will get random problems. This is done for you automatically when you implement COM with MFC, which is why there are these ugly METHOD_MANAGE_STATE macros in every method.
Beyond this, it just works. MFC objects inside a ATL objects is what I do..
I've always used straight ATL with no MFC for development of COM components. MFC is useful as an application framework, which I generally didn't need for lightweight (non-UI) COM components. ATL provides lots of support for strings, collections, and various utility classes without the need to bring in all of MFC with the logistical complexities that arise from doing that (like setting context on every public API call, etc). It also includes some basic UI support via CWindow and its friends if you're building a UI component.