.ODL/MDL file and its utility
- Wrapping a C library in COM/ActiveX
- Wrap a C library
- Simple and easy to maintain
- C++ (all projects are written in C and we use C++ when C is not a viable option)
Minimal dependencies
- Do not use MFC
- Do not use ATL
- Accessible by legacy applications
- Accessible by .Net applications
- Accessible by Internet Explorer (downloads, installs and runs an ActiveX component form a remote server)
- Step by Step COM Tutorial
- A simple yet debuggable COM skeleton code
- ActiveX Control Tutorial
- ActiveX Controls Architecture
- ActiveX Controls
- Type Library Viewers and Conversion Tools
- Using the OLE/COM Object Viewer
- If you open the shortcut menu for a control in the left pane and then choose View Type Information, the ITypeInfo Viewer displays a reconstructed .idl or .odl file.
- If you expand the control node in the left pane, a list of the interfaces in the object is displayed. If you select an interface, its registry entry is displayed in the right pane.
- If you open the shortcut menu for an interface and then choose View, the OLE/COM Object Viewer displays a dialog box that shows the GUID for the interface and an option to view type library information, if it is available. Selecting View Type Info displays a portion of a reconstructed .idl file that is specific to the interface in the ITypeInfo Viewer.
- In the ITypeInfo Viewer, you can select an interface member in the tree view to display the accessor method signatures in the right pane.
- OLE-COM Object Viewer
- On the object viewer File menu, click View TypeLib. An Open dialog box appears.
- Specify the type library file you want to open, and click OK.
- MkTypLib Command-Line Tool
- MIDL Compiler
- Generating a Type Library with MIDL
- Microsoft Interface Definition Language
- Interface Definitions and Type Libraries
- MIDL Language Reference
A Test ActiveX Control
Not very long ago my boss walked up to my desk, put a pile of books down beside me and said “Not it”. The books were all related to COM programming. The project he gave me was to create a COM wrapper for an existing C library we had developed. Windows is not my primary development platform, so I was tasked with learning COM and then writing a wrapper around our C library.
The following is based on the internal documentation I wrote during the development of our COM wrapper. I’m publishing it with permission from my employer, Main Street Softworks. Nothing contained within is specific to the project but general information about what I learned a and how I completed the task.
The goals of the project are fairly simple.
Introduction For me , understanding COM (Component Object Model) has been no less than an odyssey. I believe that every programmer who wishes to understand the basic principles behind COM, must write atleast one simple COM object using plain C++ , i.e. without the aid of templates and macros that comes along with MFC/ATL. In this article I present the guidelines for creating simple COM objects from first principles. The components should be usable by both VC/VB clients.
As an exercise we will attempt to design a COM component that will implement a hypothetical super-fast addition algorithm. The component must take in two parametes of long data type, and return to the user another long parameter that will be an outcome of our addition algorithm.We will begin with designing the interface.
This article and topic will probably inspire reluctance from code gurus. But, even after 7 years and a massive use in today's Windows-centric world, I often see people wondering the simplest questions about COM.
Microsoft introduced several years ago the ATL library, hoping that ready-to-use macros would simplify the COM development process. But in practice, the macros tend to obfuscate what the code really does and is expected to do. Furthermore, one obvious thing at the basis of this article is that ATL macros produce undebuggable code. Macros are expanded by the C/C++ preprocessor, which means it's virtually impossible to figure out what might be wrong in any ATL-based code.
That's why I shall in this article show how to write working COM components from scratch, and without a single macro. Hope you find it useful.
The remainder of this article provides three (hopefully reusable) sample COM implementations : a simple COM dll an automation-enabled COM dll an automation-enabled COM exe plus several working test environments (C/C++ and VB).
This article is for those enthusiastic VC++ developers who want to build their own ActiveX controls but don’t know where to start with. This article will take you to build your first ActiveX control. This article will show you the step by step method to build a control which draws different waveforms (Sin/Cos).I assume that you are familiar with VC++ and know some basics of ActiveX control.
,ActiveX Architecture
ActiveX controls technology builds on a foundation of many lower-level objects and interfaces in OLE. The exact interfaces available on a control vary with its capabilities. This section takes a closer look at the capabilities a control might provide.
ActiveX controls technology rests on a foundation consisting of COM, connectable objects, compound documents, property pages, OLE automation, object persistence, and system-provided font and picture objects. As summarized below, each of these core technologies plays a role in controls.
Type libraries contain the specification for one or more COM elements, including classes, interfaces, enumerations, and more. These files are stored in a standard binary format. A type library can be a stand-alone file with the .tlb file name extension, or it can be stored as a resource in an executable file, which can have an .ocx, .dll, or .exe file name extension. The type library viewers and conversion tools described following read this format to gain information about the COM elements in the library.
Before you can program an object in a particular programming language, you must be able to view its type library in that language. Doing this provides you with the proper syntax for the classes, interfaces, methods, properties, and events of the COM object.
Microsoft development products provide the following tools that you can use to generate, extract, and view type library information.
To use the OLE/COM Object Viewer Start the OLE/COM Object Viewer (oleview.exe), which is located in the \Program Files (x86)\Windows Kits\8.0\bin\x86\ folder.
In the Object Classes, Grouped by Component category in the viewer, open the Automation Objects folder to view the registered Automation objects.
Select one of the controls. Several tabs appear in the right pane; the interfaces that are implemented by the control are displayed on the Registry tab.
The OLE-COM object viewer, Oleview.exe, is an application supplied with Visual C++ that displays the COM objects installed on your computer and the interfaces they support. You can use this object viewer to view type libraries.
To view a COM object's type library:
[The Mktyplib.exe tool is obsolete. Use the MIDL compiler instead. If you need backward compatibility with old Automation programs, use the MIDL compiler with the /mktyplib203 option.]
MkTypLib is a command-line application that processes an IDL file to produce a type library. It can also be used to generate a C or C++ header file.
The MIDL compiler processes an IDL file to generate a type library and output files. The type of output files generated by the MIDL compiler depends on the attributes specified in the IDL file's interface attribute list.
If the attribute list contains the [object] keyword, the MIDL compiler generates COM interface output files: an interface proxy file, an interface header file, and a globally unique identifier (GUID) file for the interface.
If the IDL file contains a library statement, MIDL generates a type library file with the .tlb file name extension.
If there are any interfaces in the IDL file that do not have the [object] keyword and are not enclosed in a library statement, the MIDL compiler generates interface output files appropriate for remote procedure calls (RPCs): a client stub file, a server stub file, and a header file. For more information, see the topics Interface Definitions and Type Libraries and Generating a Type Library with MIDL..
The top-level element of the ODL syntax is the library statement (library block). Every other ODL statement, with the exception of the attributes that are applied to the library statement, must be defined within the library block. When the MIDL compiler sees a library block, it generates a type library in much the same way that MkTypLib does. With a few exceptions, described in Differences Between MIDL and MKTYPLIB, the statements within the library block should follow the same syntax as in the ODL language and MkTypLib.
Purpose The Microsoft Interface Definition Language (MIDL) defines interfaces between client and server programs. Microsoft includes the MIDL compiler with the Platform Software Development Kit (SDK) to enable developers to create the interface definition language (IDL) files and application configuration files (ACF) required for remote procedure call (RPC) interfaces and COM/DCOM interfaces. MIDL also supports the generation of type libraries for OLE Automation.
his section presents information about how to create interface definition language (IDL) files and application configuration files (ACF) for MIDL, including reference pages for IDL and ACF attributes. There is also information about how to import files, type libraries, and system header files.
This section provides a reference entry for each keyword in the Microsoft Interface Definition Language (MIDL). Reference entries are also included for important language productions and concepts.
This is a paragraph.
This is a paragraph.
This is a paragraph.
This is a paragraph.
This is a paragraph.
No comments:
Post a Comment