Any good, recent MFC Control Container examples?

[Rob McCurley]

I'm looking for a good example of an OLE container for ActiveX controls.
I've found Mike Blaszczak's excellent article "Implementing OLE control
Containers with MFC and the OLE Control Developer's Kit", and the
accompanying project file. (FYI: This article and example are on the MSDN
Library CD.) However, this article was posted in the April 95 MSJ and is
almost two years old. Can any suggest or provide another example?

--
Rob McCurley (ro...@worldnet.att.net)
Portable Systems Technology, Inc.
Atlanta, Georgia

[Brent McClure]

In article <01bc1a8e$dfde5760$83a885c6@hubris>,

Rob McCurley <ro...@worldnet.att.net> wrote:
>
>I'm looking for a good example of an OLE container for ActiveX controls.
>I've found Mike Blaszczak's excellent article "Implementing OLE control
>Containers with MFC and the OLE Control Developer's Kit", and the
>accompanying project file. (FYI: This article and example are on the MSDN
>Library CD.) However, this article was posted in the April 95 MSJ and is
>almost two years old. Can any suggest or provide another example?

I've been looking for this too and it doesn't seem like there is
much out there. I too found that article and another one titled

"Putting Your OLE Controls to Work with Microsoft Access, Visual Basic, and
C++", by Joshua Trupin. MSJ, Feb 1995.

This article had a similar app that worked in almost the same way where
I believe they extend the COleClientItem class to have the other necessary
container-side interfaces. Anyhow this example is pretty old too, but it
may be worth looking at.

Unfortuately I don't think MFC has anything better for doing on-the-fly
control containment. As you probably know the provided support is for
hard-wired controls only.

There is another example I got off of the microsoft.com/oledev site and
it was the source code for their "verification container", VCONTAIN I
think it was called. Anyhow it was interesting but even less useful because
it actually linked directly to things like COleControlContainer and
CControlSite classes in the MFC source with the warning in their
source code that it was a risky thing to do for future compatability.
anyhow I didn't consider that a useful idea to model.

Lastly I've been leaning back toward thinking that its best just to gut
it out and do it with straight C++/COM like the Brockschmidt Chap 24 "patron"
app does it. You have to implement everything yourself, but you don't
have MFC in the way if you need to get your hands dirty. And besides if
you want to really get fancy and support windowless controls, message
reflection, etc. then I'm not sure if MFC will help much there either
(except maybe reading their source code to see how they do it :)

That's all I've scratched up in a few months of poking around. If you turn
up anything else I'd love to hear about it.

--Brent

[Kristopher D. Johnson]

After a couple months of futzing around, I finally have a MFC
COleClientItem-based control container which supports many of the OCX96
interfaces (windowless controls, quick-activation, and multilevel undo). I
started this project knowing nothing about OLE, MFC, or Windows
programming, so having the COleClientItem base to build upon was very
helpful. What I ended up with was a subclass of COleClientItem with a
bunch of code based upon (or copied directly from) Brockschmidt's Patron,
Trupin's article, and MFC's COleControlContainer source code.

I agree that someone who knows what they're doing would be better off doing
it from scratch. I'm not sure I'd get rid of MFC totally, but I'd
definitely avoid COleClientItem and the other aspects of MFC's container
implementation.

The big problems with COleClientItem in a control container are:

- no support for the OLEMISC_SETCLIENTSITEFIRST bit

- no support for IPersistStream or IPersistStreamInit

- problems with activating more than one object

I had to override a lot of COleClientItem's functions to get around those
problems. Other aspects of control containment (ambient properties,
handling events, design/run mode, etc.) simply involve adding new code; the
problems above require major changes to MFC's implementation.

I know you'd probably like me to post the code, but I don't think my
employer would allow it. I'd be happy to answer questions, however.

----------------------------------------------------------
Kristopher Johnson, Systems Engineer
TransCore (formerly JHK & Associates), An SAIC Company
Phone: 770-447-6831
Fax: 770-449-7268
Email: kristopher...@cpmx.saic.com

Brent McClure <mcc...@swcp.com> wrote in article
<uU0ta9r...@uppssnewspub04.moswest.msn.net>...

[snip]

[Trip Denton]

Dynamically creating an OCX control is easy (Once you know how).
First create a
CWnd *pOCXWnd=new CWnd;
bMade=m_pcwOCX->CreateControl(
m_csCLSID,
NULL,
dwStyle,
m_rectWhere,
pParent,
m_iInstanceID //, NULL, FALSE,
NULL
);

m_csCLSD is the class id of the control you want
dwStyle is the style
m_iIntanceID some int you choose.

Once you've made it then you can manipulate it with
m_pcwOCX->SetProperty(dispID,VT_BSTR,csValue);

etc etc. The real tough part is parsing the type lib.
Oh yeah to respond to event you need to modify your
OnCmdMsg handler.

Calling the methods can be abit hairy too.
I use code like this
LPUNKNOWN pUnk=m_pcwOCX->GetControlUnknown();

if (pUnk)
{
pUnk->AddRef();
IDispatch *pDispatch=NULL;


if (bOK && SUCCEEDED(pUnk->QueryInterface(IID_IDispatch,(void
**)&pDispatch)))
{
//TRACE("pDispatch=%p\n",pDispatch);
try
{
if (SUCCEEDED(pDispatch->Invoke(dispID,
IID_NULL,LOCALE_USER_DEFAULT,wFlags,&dispParams,&varResult,0,0)))
{
bOK=TRUE;
}

}
catch (...)
{
bOK=FALSE;
}
pDispatch->Release();
}

pUnk->Release();
}

The hard part is packing the params.
--
Trip Denton
V_Graph Inc.
tde...@zola.trend1.com