One MDI program acts as OLE Container and OLE Server : Is th

Lee Jae Kil -- juria@seodu.co.kr
Saturday, April 20, 1996


Environment: VC++ 4.0 / Win 95 or Win NT
(Not Environment specific.)

Hi, everyone.

I want to merge two application as one.
App1 - MDI application OLE container : Compund Document, Need not support inplace editing.
App2 - MDI application OLE server : Act as ordinary OLE server.

For example, MFC OLE samples have DrawClient, and Scribble OLE server.
I've tried merging two application as one.
If I insert object other that scribble, then OK.
If I insert scribble object, I can't.

Above functionality is similar visio,
which has template as container(no inplace editing, show only iconic shape), drawing window as server.


I can make the functionality not using OLE.
But can this situation possible using OLE and/or MFC.

There are OLE inproc server, inproc handler, local server, remote server.
But none of these are above situation.

Any reply is appreciated.

TIA

 ----
 Lee, Jae Kil : juria@seodu.co.kr

---

Brad P. Exchange -- Brad.P.Smith@Cognos.COM
Friday, April 26, 1996

>>
>From: 	Lee Jae Kil[SMTP:juria@seodu.co.kr]

I want to merge two application as one.
App1 - MDI application OLE container : Compund Document, Need not
support inplace editing.
App2 - MDI application OLE server : Act as ordinary OLE server.

For example, MFC OLE samples have DrawClient, and Scribble OLE server.
I've tried merging two application as one.
If I insert object other that scribble, then OK.
If I insert scribble object, I can't.

Above functionality is similar visio,
which has template as container(no inplace editing, show only iconic
shape), drawing window as server.

I can make the functionality not using OLE.
But can this situation possible using OLE and/or MFC.

There are OLE inproc server, inproc handler, local server, remote
server.
But none of these are above situation.
<<

It's certainly possible to have a single app be both a Container and
Server. What you *can't* do, at least via MFC, is embed an object of
yourself as yourself.

We ran into this a while ago, and a KnowledgeBase article was written on
this after we posed a question to MS (we're on Premier Support).
Essentially, MFC cannot handle "self-embedding". The article (Q121949)
clearly explains why this is very difficult to achieve, and I don't
think you can work around that limitation.

Unfortunately, MFC also fails to *prevent* your application from
attempting to insert yourself. This is unfortunate since the code to do
this is reasonably simple.  Below is a slightly sanitized version of
what I ended up writing. You'd want to put this inside a TRY/CATCH
block, but otherwise you can use it almost verbatum.

--- cut here ---
COleInsertDialog dlg;// We won't support embedding our doc inside
another of our docsCImpDoc *pDoc =
(CImpDoc*)(pView->GetDocument());CLSID myClsid =
pDoc->m_pFactory->GetClassID();dlg.m_io.cClsidExclude =
1;dlg.m_io.lpClsidExclude =
(LPCLSID)&myClsid;dlg.SetHelpID(IDD_INSERT_OLE_OBJECT);if (dlg.DoModal()
!= IDOK)    AfxThrowMemoryException();  // any exception will do// The
user can still do a "Create From File" of one of our// file types. We
need to trap that. Unfortunately, it seems the// only "reliable" method
is by comparing extensions. if( dlg.m_io.lpszFile &&
*(dlg.m_io.lpszFile) ){    char ext[_MAX_EXT];    _splitpath(
dlg.m_io.lpszFile, NULL, NULL, NULL, ext );    if( ext && *ext )    {   
    _fstrupr( ext );
        CString reportExt;        CString templateExt;       
reportExt.LoadString(IDS_REPORT_EXT);        reportExt.MakeUpper();     
  templateExt.LoadString(IDS_TEMPLATE_EXT);       
templateExt.MakeUpper();        if( !reportExt.CompareNoCase( ext ) ||  
             !templateExt.CompareNoCase( ext ) )        {           
ImpMessageBox(IDP_SELF_EMBED_REJECTED);           
AfxThrowMemoryException();  // any exception will do        }    }}---
cut here ---

BTW, if somebody can think of a better way to handle the "Create From
File" problem other than comparing extensions, I'd love to hear about
it. :-)

Hope this helps;
Brad.

---

| Вернуться в корень Архива |