Original Post
🔒 Locked
using activeX Controls only with win API
Advertisement
Unfortunately there''s a contradiction in what you''re asking for:
"tutorial" - there''s a complete book called Inside OLE.
"short example" - umm not really possible - see below.
ActiveX controls are really what used to be known as OLE Controls. The basic stuff which holds them together is COM.
If the ActiveX control you wish to use...:
a) doesn''t have **ANY** user interface
b) hasn''t been written with one of the old MFC control wizards ("bloatware" alert)
...Then if you''re lucky, assuming the object is correctly registered etc you should be able to do something like (from memory so parameters not filled in - look on MSDN for full details):
CoInitialize();
CoCreateInstance(..blah.. IID_OfTheControlYouWantToUse ..blah..);
The pointer you''ll get back from the CoCreateInstance should be that of an IUnknown interface, you then call IUnknown::QueryInterface to get any other interface, you''ll probably be most interested in IDispatch which is what you use to invoke methods exported by the control (using IDispatch::Invoke). You also use Invoke to set properties on the control.
To release stuff, just call ::Release() on its interface (a COM thing - all interfaces are reference counted - IUnknown''s refcount is first bumped when you CoCreateInstance(), the control is unloaded when you call the final Release on that).
Unfortunately
-------------
1) To be useful most ActiveX controls have some form of user interface (input or output).
2) Most people making ActiveX controls are after the shortest engineering time rather than the most efficient code so they use the MFC ControlWizard. Controls built using the MFC Wizard usually have some form of user interface, even when it''s not being used.
As soon as a control has any form of user interface, then the work required to use a control manually ("only with Windows API functions") goes up at least 1000%
A control (with UI) expects to be loaded into "A container", an MFC ControlWizard control expects a fully featured container.
The container is a set of COM interfaces supplied by your application which tell the control all sorts of things about where it lives. To get an idea about the sort of things communicated, imagine a shockwave flash control on a webpage in a browser such as IE:
When the page is scrolled, resized, obscurred etc, the control needs to know so that it can update its output. And your app needs to know similar things from the control.
To write a proper container using plain Windows you need to learn all about the relevent COM, OLE and ActiveX interfaces. If you need to do that from scratch I''d recommend getting hold of "Inside OLE".
Some advice:
------------
1) Don''t write a container from scratch unless you REALLY need to.
2) If there are only a few methods and properties you want access to in the control then make a DLL with MFC which has a full container and wraps up the methods you need to get at, then load the DLL into your non-MFC app.
3) Even if you don''t want to use any MFC, definately look at ATL, it''ll make the boring parts of writing a container MUCH easier.
4) If you still really must use your own container, get one which has already been written - such as the one which comes with Inside OLE
[The above comes from bitter, painful experience about 5 years ago of being forced to make a program which used pure Windows API and DirectX use a MFC based ActiveX control]
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
"tutorial" - there''s a complete book called Inside OLE.
"short example" - umm not really possible - see below.
ActiveX controls are really what used to be known as OLE Controls. The basic stuff which holds them together is COM.
If the ActiveX control you wish to use...:
a) doesn''t have **ANY** user interface
b) hasn''t been written with one of the old MFC control wizards ("bloatware" alert)
...Then if you''re lucky, assuming the object is correctly registered etc you should be able to do something like (from memory so parameters not filled in - look on MSDN for full details):
CoInitialize();
CoCreateInstance(..blah.. IID_OfTheControlYouWantToUse ..blah..);
The pointer you''ll get back from the CoCreateInstance should be that of an IUnknown interface, you then call IUnknown::QueryInterface to get any other interface, you''ll probably be most interested in IDispatch which is what you use to invoke methods exported by the control (using IDispatch::Invoke). You also use Invoke to set properties on the control.
To release stuff, just call ::Release() on its interface (a COM thing - all interfaces are reference counted - IUnknown''s refcount is first bumped when you CoCreateInstance(), the control is unloaded when you call the final Release on that).
Unfortunately
-------------
1) To be useful most ActiveX controls have some form of user interface (input or output).
2) Most people making ActiveX controls are after the shortest engineering time rather than the most efficient code so they use the MFC ControlWizard. Controls built using the MFC Wizard usually have some form of user interface, even when it''s not being used.
As soon as a control has any form of user interface, then the work required to use a control manually ("only with Windows API functions") goes up at least 1000%
A control (with UI) expects to be loaded into "A container", an MFC ControlWizard control expects a fully featured container.
The container is a set of COM interfaces supplied by your application which tell the control all sorts of things about where it lives. To get an idea about the sort of things communicated, imagine a shockwave flash control on a webpage in a browser such as IE:
When the page is scrolled, resized, obscurred etc, the control needs to know so that it can update its output. And your app needs to know similar things from the control.
To write a proper container using plain Windows you need to learn all about the relevent COM, OLE and ActiveX interfaces. If you need to do that from scratch I''d recommend getting hold of "Inside OLE".
Some advice:
------------
1) Don''t write a container from scratch unless you REALLY need to.
2) If there are only a few methods and properties you want access to in the control then make a DLL with MFC which has a full container and wraps up the methods you need to get at, then load the DLL into your non-MFC app.
3) Even if you don''t want to use any MFC, definately look at ATL, it''ll make the boring parts of writing a container MUCH easier.
4) If you still really must use your own container, get one which has already been written - such as the one which comes with Inside OLE
[The above comes from bitter, painful experience about 5 years ago of being forced to make a program which used pure Windows API and DirectX use a MFC based ActiveX control]
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement