I guess the question is, do you want an MFC COM Server with ATL support or
an ATL COM project with MFC support?
Brian
Yeah. Turns out you can add ATL support to an MFC project but not the other
way around.
Now I'm struggling with registration. The reason I asked the original
question is I'm
trying to update my project to not use the deprecated DECLARE_REGISTRY and
instead
use RGS files and needed a sample.
Here's the question now. Do I need to have an RGS file for every interface,
even the noncreatable ones? Please say "no" as there are 163 of them.
Thanks,
Drew
>
> Brian
>
>
Not true. Both scenarios are supported.
> Now I'm struggling with registration. The reason I asked the original
> question is I'm
> trying to update my project to not use the deprecated DECLARE_REGISTRY and
> instead
> use RGS files and needed a sample.
>
> Here's the question now. Do I need to have an RGS file for every
> interface,
> even the noncreatable ones?
I've heard of non-creatable objects, but not non-creatable interfaces.
Non-creatable objects do not need to be registered.
Brian
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnic...@mvps.org
MVP VC FAQ: http://vcfaq.mvps.org
=====================================
"Brian Muth" <bm...@mvps.org> wrote in message
news:uyfDNzQr...@TK2MSFTNGP05.phx.gbl...
OK, here's what I've done based on what I saw in my sample app (sorry for
length):
I've created 2 RGS files, one for the project in general and one for my only
creatable object.
I've put these in my resource only DLL which I load at the beginning of
InitInstance()
1st one:
HKCR
{
NoRemove AppID
{
'%APPID%' = s 'MyApp'
'MyApp.EXE'
{
val AppID = s '%APPID%'
}
}
}
2nd one:
HKCR
{
MyApp.Application.2 = s 'Application Class'
{
CLSID = s '{684A3F62-0408-11d4-A05F-0050DA1AC1A8}' // coclass uuid
}
MyApp.Application = s 'Application Class'
{
CLSID = s '{684A3F62-0408-11d4-A05F-0050DA1AC1A8}' // coclass uuid
CurVer = s 'MyApp.Application.2'
}
NoRemove CLSID
{
ForceRemove {684A3F62-0408-11d4-A05F-0050DA1AC1A8} = s 'ATLApp Class' //
coclass uuid
{
ProgID = s 'MyApp.Application.2'
VersionIndependentProgID = s 'MyApp.Application'
ForceRemove 'Programmable'
LocalServer32 = s '%MODULE%'
val AppID = s '%APPID%'
'TypeLib' = s '{684A3F60-0408-11d4-A05F-0050DA1AC1A8}' // type library
uuid
}
}
}
Then in my CWinApp derived class at global scope:
class CATLHostModule : public CAtlMfcModule
{
public :
DECLARE_LIBID(LIBID_StressCheck)
// It seems the GUID here is arbitrary
DECLARE_REGISTRY_APPID_RESOURCEID(IDR_MFCAPP,
"{2D612497-139A-47d9-A08C-A2286D24B406}")
};
CATLHostModule _Module;
// type library uuid
const GUID CDECL BASED_CODE _tlid =
{ 0x684A3F60, 0x0408, 0x11d4, { 0xA0, 0x5F, 0x00, 0x50, 0xDA, 0x1A, 0xC1,
0xA8 } };
const WORD _wVerMajor = 2;
const WORD _wVerMinor = 0;
Then in InitInstance:
// Following was copy/pasted out of sample app
// App was launched with /Embedding or /Automation switch.
// Run app as automation server.
if (cmdInfo.m_bRunEmbedded || cmdInfo.m_bRunAutomated)
{
// Don't show the main window
return TRUE;
}
// App was launched with /Unregserver or /Unregister switch. Unregister
// typelibrary. Other unregistration occurs in ProcessShellCommand().
else if (cmdInfo.m_nShellCommand == CCommandLineInfo::AppUnregister)
{
_Module.UpdateRegistryAppId(FALSE);
_Module.UnregisterServer(TRUE);
UnregisterShellFileTypes();
m_server.UpdateRegistry(OAT_DISPATCH_OBJECT, NULL, NULL, FALSE);
AfxOleUnregisterTypeLib(_tlid, _wVerMajor, _wVerMinor);
}
// App was launched standalone or with other switches (e.g. /Register
// or /Regserver). Update registry entries, including typelibrary.
else
{
/************ RELEVANT CODE (I think) ***********/
m_server.UpdateRegistry(OAT_DISPATCH_OBJECT);
COleObjectFactory::UpdateRegistryAll(); // returns 0
_Module.UpdateRegistryAppId(TRUE); // returns 0x80070716 The specified
resource name cannot be found in the image file.
_Module.RegisterServer(TRUE); // same as above
AfxOleRegisterTypeLib(AfxGetInstanceHandle(), _tlid); // returns 0
}
I can understand the HRESULTs if it is using the arbitrary GUID
from the DECLARE_REGISTRY_APPID_RESOURCEID macro, but this is
how it was done in the generated sample app. I'm stuck.
Thanks,
Drew
>
> Brian
>
>
>
ATL doesn't support placing registration scripts into a separate
resource DLL. Bind them directly to the module being registered.
The reason is ATL uses CAtlBaseModule::GetModuleInstance to figure out
which module to load RGS resources from, rather than
GetResourceInstance. This is arguably a bug.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
Drew
"Igor Tandetnik" <itand...@mvps.org> wrote in message
news:ucYcGfSr...@TK2MSFTNGP06.phx.gbl...