How can I get class name of a document in my program. I mean, I have done this:
pDocTemplate = new CMultiDocTemplate(
IDR_FRAMETYPE,
RUNTIME_CLASS(CFrameDoc2D),
RUNTIME_CLASS(CEditorChildFrame),
RUNTIME_CLASS(CFrameView));
gl_pDocTemplateManager->AddTemplateInfo("CMyDoc", eStructure);
AddDocTemplate(pDocTemplate);
I want to get CMyDoc string in another project (.dll) of my MSVC solution via CDocument class. I can't cast to a specific document class due to cyclic dependencies.
I'm not sure what AddTemplateInfo() does, it does not seem to be a standard MFC function.
To get the name of the class, you could use something like:
CRuntimeClass *pClass = pDoc->GetRuntimeClass();
if (pClass != NULL)
TRACE(_T("Document class = %S\n"), pClass->m_lpszClassName);
NOTE: m_lpszClassName is ASCII (LPCSTR) and the code above assumes your project is based on Unicode -- otherwise, change %S to %s.
Related
Say I have this class:
public ref class Page1 sealed : Windows::UI::Xaml::Controls::Page {};
I can activate an instance of this class like this:
auto page = ref new Page1();
But how would I do that in raw C++?
I have tried this but it doesn't work:
Microsoft::WRL::Wrappers::HString className;
className.Set(L"App1.Page1");
IInspectable *page;
Windows::Foundation::ActivateInstance(className.Get(), &page);
The above code does work when I specify a windows runtime class name, (such as "Windows.UI.Xaml.Controls.Button"), just not my own ref class "App1.Page1".
Alternatively, given that I have declared a public ref class named Page1 in the App1 namespace, how can I activate an instance of this class as an IInspectable* from the HSTRING "App1.Page1"?
I think I have figured it out. Well, this answer does not directly solve the problem of activating any arbitrary type, but it does what I want.
The devil is in the detail. The XAML compiler will generate a bunch of files not visible in the Solution Explorer. These files have the extension .g.h and .g.hpp. You can click the "Show All Files" button in Solution Explorer to see them.
In App.g.h, the App class implements the Windows::UI::Xaml::Markup::IXamlMetadataProvider class, which we can use to obtain information about our XAML types. The XamlTypeInfo files contains the generated type definitions.
Here's some code which shows how to activate one of our XAML types from a TypeName:
Object^ activate(TypeName typeName)
{
auto app = Application::Current;
auto provider = static_cast<IXamlMetadataProvider^>(app);
auto xamlType = provider->GetXamlType(typeName);
return xamlType->ActivateInstance();
}
No WRL necessary, 100% C++/CX, thanks to the XAML type information generated by the XAML compiler!
I believe a similar structure is also the case for C# projects, in that the Application-derived class will implement IXamlMetadataProvider interface too. Under the hood, the Windows Runtime does not use .NET, so it does not have any kind of "real" reflection, so it relies on statically defined type definitions.
I have C++ solution with some apps and static libraries:
UserRace1.exe
UserRace2.exe
GreenBody.lib
BlueBody.lib
RedBody.lib
BigWheels.lib
MiddleWheels.lib
SmallWheels.lib
V8Engine.lib
V12Engine.lib
RaceTires.lib
WinterTires.lib
SimpleTires.lib
Garage.lib
In application, I just simulate race, one application for each race. Libs consist classes that describe parts of the car (body, wheels, engine, etc.). Every class implement some interface (IBody, IWheels, IEngine, etc.), that described in Garage lib. And Garage.lib should create cars, using parts.
So, I pass car parameters to application, as example: -Car1 -RedBody -MiddleWheels -V8Engine -RaceTires -Car2 -BlueBody -SmallWheels -V12Engine -WinterTires . Application call Garage class: Garage::GetCar(string body, string wheels, string engine, string tires) and garage return Car object, that we use in app. Pay attention, that I pass this arguments like a string. It's important.
Now, about what I want. I write only Garage lib. Other libs will be write by other people. And I want my library has been universal. At this moment, when new part added (e.g. BlackBody.lib) I must add support of this in my Garage.lib. something like:
...
else if (body == "RedBody")
{
car->body = new RedBody();
}
else if (body == "BlackBody")
{
car->body = new BlackBody();
}
...
But I want to get this types dynamicaly. Like:
foreach (Librarian lib in Application.GetLibs())
{
foreach (Type type in lib)
{
if (type is IBody)
{
if (((IBody)type)::GetColor() == color)
{
car->body = type.GetInstance();
return;
}
}
}
}
Then, if someone add new type, I will not change my library. Problem is, that I write on C++, not C#. And I don't know how to implement it.
Maybe I should use dll instead of static lib? Is this an only way? And if so, whether there would be problems that the applications and dlls use one library (Garage.lib)? Cause they use different runtime libraries (/MT and /MD).
You could have an entirely "dynamic" solution, using DLLs, provided that:
you could derive a Dll name ("BlackBody.dll") from a string '"BlackBody")
each Dll exports a factory function, with a predictable name ("Factory", or "BlackBodyFactory")
You dynamically load the Dlls, and get the factory pointer function via GetProcAddress
your Garage.lib code only knows about the Body base class, because that's what a "body" factory function will return
You should avoid mixing different CRT in the same process. Mixing is possible but involves extra care/work.
I have a com dll that gets used in a c++ project. I have not registered the dll but its in the same solution. My application continuously breaks and I found that it breaks here
hr = CoCreateInstance(rclsid, pOuter, dwClsContext, __uuidof(IUnknown), reinterpret_cast<void**>(&pIUnknown));
because I don't have a com class with that guid (rclsid). I did more digging and I found that it gets the guid from a .tlh file in a temp directory but the guid differs from my code.
.tlh file
struct __declspec(uuid("b10a18c8-7109-3f48-94d9-e48b526fc928"))
DocMapEntry;
// [ default ] interface _DocMapEntry
// interface _Object
// interface IDocMapEntry
c# code (com visable dll)
[ComVisible(true)]
[Guid("E98676B9-1965-4248-A9B6-74EC5EE5385A")]
[InterfaceType(ComInterfaceType.InterfaceIsDual)]
public interface IDocMapEntry
{
int Offset { get; set; }
int PageOffset { get; set; }
int PageNumber { get; set; }
}
I tried changing the value to the correct value but it continuously gets changed and visual studio asks me to reload.
When I look at the class using com explorer I get a different clsid, and when I try to unregister it, it completes successfully but the item is still there and the file location is mscoree.
my c++ application uses the guid in the .tlh file but doesn't find the file.
public class DocMapEntry : IDocMapEntry
{
...
}
My questions are.
Do I need to register my com dll for this to work?
how can I set the guid for the class?
Why would it create a temp .tlh file with the wrong guid? (optional)
why can't I change this file? (optional)
Thank you.
public interface IDocMapEntry
COM strongly distinguishes between a CLSID and a IID. The IID, the interface identifier, identifies an interface implemented by a COM object. We can see that one, you specified it with the [Guid] attribute. You'd pass it as the 4th argument of CoCreateInstance(), the one where you now pass the IID of IUnknown.
What you need is the CLSID, the class identifier. We can't see it in your snippet, it is the one for whatever class implements your IDocMapEntry. With some odds that it is named DocMapEntry. And additional odds that you didn't give it a [Guid] so the CLR will auto-generate one for you. Note that it will change when you modify the class, one possible reason for CoCreateObject() to fail.
Forgetting to register the .NET assembly with Regasm.exe /codebase is another reason, you stated as much in your question. This is required or COM will not be able to find the DLL and fails the call with error code 0x80040154, "Class not registered". Having it in the same solution is not sufficient, COM search rules are not anything like those used by .NET.
Also note that you are exposing the internals of the class, avoid that by applying the [ClassInterface(ClassInterfaceType.None)] attribute on the class.
No you do not have to register the COM DLL but you do need to register an object responsible for creating the COM objects. Use do this in your application by calling CoRegisterClassObject after the COM subsystem has been initialized (by calling CoInitialize or CoInitializeEx).
IClassFactory *factory = new ObjectFactory();
// Register the factory responsible for creating our COM objects
DWORD classToken;
HRESULT hr = CoRegisterClassObject(
Object_CLSIID,
factory,
CLSCTX_LOCAL_SERVER,
REGCLS_MULTIPLEUSE,
&classToken);
// Now we can create the objects
Object *obj = nullptr;
hr = CoCreateInstance(
Object_CLSIID,
nullptr,
CLSCTX_LOCAL_SERVER,
Object_IID,
reinterpret_cast<void**>(&obj));
Not sure why it's creating a temporary .tlh but I suspect it's something in your build settings - possibly in the build steps.
Is your COM object in a C# dll ? If yes, did you run regasm previously in your system, which could have registered the COM dll.
Guid("E98676B9-1965-4248-A9B6-74EC5EE5385A"): This is your interface GUID, not your component guid.
You should have a GUID declared for COM object in the implementation class, which should be b10a18c8-7109-3f48-94d9-e48b526fc928.
Why would it create a temp .tlh file with the wrong guid?
Are you sure you have not imported the COM dll using #import keyword.
My question is similar to Getting CLSID for a DLL file?, I think.
I have a directory with some DLLs, each one implementing one or more COM interfaces. I would like to get:
1) Each interface name
2) The CLSID of the class implementing the interface
For each DLL. It's important that everything can be done programatically (So I can't use some sort of COM browser and manually look up for that information).
Later I will lookup the CLSID given the interface name and call some methods using IDispatch.
One alternative seems to be scanning the registry trying to match the type, interface and class GUID and the .dll filename. But that seems to be slow and not robust.
Does someone has a clear solution to this problem?
EDIT:
With the response of Ben Voigt, I came with the following code which suit my needs:
ITypeLib *typelib;
ITypeInfo *typeinfo;
LoadTypeLibEx(_T("c:\\mydir\\mycom1"), REGKIND_NONE, &typelib);
for (UINT i = 0;i < typelib->GetTypeInfoCount();++i) {
TYPEKIND typekind;
typelib->GetTypeInfoType(i, &typekind);
if (typekind == TKIND_COCLASS) {
// class!
CComBSTR className;
TYPEATTR *typeattr;
typelib->GetTypeInfo(i, &typeinfo);
typeinfo->GetDocumentation(MEMBERID_NIL, &className, NULL, NULL, NULL);
typeinfo->GetTypeAttr(&typeattr);
GUID classGUID = typeattr->guid;
for (UINT j = 0;j < typeattr->cImplTypes;++j) {
// interface!
CComBSTR interfaceName;
HREFTYPE hreftype;
ITypeInfo *classtypeinfo;
typeinfo->GetRefTypeOfImplType(j, &hreftype);
typeinfo->GetRefTypeInfo(hreftype, &classtypeinfo);
classtypeinfo->GetDocumentation(MEMBERID_NIL, &interfaceName, NULL, NULL, NULL);
// associate interfaceName with classGUID here
}
}
}
You can't get that from the COM DLL, but you can get it from the typelib. I'm pretty sure the MIDL compiler has a switch to decompile a typelib, but parsing IDL wouldn't be as easy as using the TypeLib API.
To complicate matters, the typelib is often stored as a resource inside the DLL. So you'd extract the resource, and open it with the TypeLib API.
Start with LoadTypeLibEx which will return you an ITypeLib* interface pointer (you knew you were going to need COM in order to get information about COM libraries, right?). This will actually do the resource extraction step for you.
Then, call ITypeLib::GetTypeInfoCount to find out how many types there are. Call ITypeLib::GetTypeInfoType for each one to find the interfaces and coclasses. And call ITypeLib::GetTypeInfo followed by ITypeInfo::GetDocumentation to get the name.
It looks like you have all of this so far. Next you need the GUID of the type, which is gotten with ITypeInfo::GetTypeAttr (not ITypeLib::GetLibAttr). That gives you a TYPEATTR structure, which has a guid field.
From the same TYPEATTR structure, you'll need the cImplTypes field. That together with ITypeInfo::GetRefTypeOfImplType will let you match up each coclass to the interfaces it implements.
Note that there's not guaranteed to be a 1:1 relationship between interfaces and implementation coclasses. And the interface can be in a different library from the coclass.
Few caveats to Ben Voigt's answer: not every COM DLL has a typelib. In your case, it seems, it does; but that's not a requirement. The only rock-solid requirement is that the DLL exports the function DllGetClassObject(), where you pass a CLSID and get back an object factory.
You could load the library and call DllGetClassObject for every registered CLSID on the system (scan the registry under HKCR\CLSID for the list of those). The ones where you get a valid object back are the ones that the DLL supports. Now, in theory, it's not even a requirement that the CLSIDs the DLL supports are registered; I can envision a DLL that implements private object classes that only the intended client knows about and no one else should. But this is a very, very exotic scenario; for one thing, the regular COM mechanism of looking up the DLL path by the CLSID will break for those. The client would have to load the DLL directly.
You could also scan the registry for the CLSID's where the DLL under consideration is registered as InprocServer32; this, again, will break in case of private classes. You can do a registry search in regedit, search in data. Also, you'd have to deal with filename case issues, short vs. long names, hardlinks, environment variable substitution and so on. So I would not recommend it.
EDIT: just thought of another way. Download Regmon, run it, and call regsvr32 on the DLL. Then watch what CLSID's are touched.
You might want to look at the source code in WiX's heat utility, which does the same thing:
http://wix.sourceforge.net/manual-wix3/heat.htm
I am some ATL code that uses smart COM pointers to iterate through MS Outlook contacts, and on some PC's I am getting a COM error 0x80004003 ('Invalid Pointer') for each contact. The same code works fine on other PCs. The code looks like this:
_ApplicationPtr ptr;
ptr.CreateInstance(CLSID_Application);
_NameSpacePtr ns = ptr->GetNamespace(_T("MAPI"));
MAPIFolderPtr folder = ns->GetDefaultFolder(olFolderContacts);
_ItemsPtr items = folder->Items;
const long count = items->GetCount();
for (long i = 1; i <= count; i++)
{
try
{
_ContactItemPtr contactitem = items->Item(i);
// The following line throws a 0x80004003 exception on some machines
ATLTRACE(_T("\tContact name: %s\n"), static_cast<LPCTSTR>(contactitem->FullName));
}
catch (const _com_error& e)
{
ATLTRACE(_T("%s\n"), e.ErrorMessage());
}
}
I wonder if any other applications/add-ins could be causing this? Any help would be welcome.
FullName is a property and you do the GET operation (it's probably something like this in IDL: get_FullName([out,retval] BSTR *o_sResult)). Such operation works ok with null values.
My assumption is that contactItem smart pointer points to any valid COM object. In such case the formatting operation done by ATLTRACE can cause the problem. Internally it behaves probably like standard sprintf("",args...) function.
To avoid such problems just do something like below:
ATLTRACE(_T("\tContact name: %s\n"),
_bstr_t(contactitem->FullName)?static_cast<LPCTSTR>(contactitem->FullName):"(Empty)")
Just a guess:
Maybe the "FullName" field in the address book is empty and that's why the pointer is invalid?
hard to tell, because your code doesn't indicate which COM-interfaces you're using.
Does this make any difference?
ATLTRACE(_T("\tContact name: %s\n"), static_cast<LPCTSTR>(contactitem->GetFullName()));
In my example you format NULL value to a proper text value.
If the question is about the difference between FullName(as a property) and GetFullName() (as a method) then the answer is no. Property and method should give the same result. Sometimes property can be mapped to different methods then setXXX and getXXX. It can be achieved by using some specific syntax in IDL (and in reality in TLB after compilation of IDL to TLB). If property FullName is not mapped to method GetFullName then you will achieve different result.
So please examine file *.tlh after importing some type library to your project...