我在一个多文档框架下通过void CMyDoc::Serialize(CArchive& ar)
{
if (ar.IsStoring())
{
}
else
{
}
}来保存和打开一个自己的文档，完全正常。可是我现在需要在一个dll中去解析这个文档，要怎么样做呢，能否贴点代码看看啊?
{
if (ar.IsStoring())
{
}
else
{
}
}来保存和打开一个自己的文档，完全正常。可是我现在需要在一个dll中去解析这个文档，要怎么样做呢，能否贴点代码看看啊?
我现在在dll中有一个函数：ParseFile(const CString& strFile)
后面代码大概怎么样啊？
中调用不就行了？
可以的啊，可是其他应用程序怎么构造这个CArchive& ar参数，该应用程序不是一个Document，没有Serialize的。
CFileException ex;
CFile file; if (!file.Open(strFile, CFile::modeRead|CFile::shareExclusive, &ex))
return FALSE;
CArchive ar(&file, CArchive::load);
我这样先构造出来的ar，解析出的内容是不对的。
// 打开文件
LPCOLESTR lpsz = strFile.GetString();
LPSTORAGE lpStorage = NULL;
SCODE sc = StgOpenStorage(lpsz, NULL, STGM_READ | STGM_TRANSACTED, 0, 0, &lpStorage);
if (FAILED(sc))
return FALSE; CFileException ex;
COleStreamFile file; if (!file.OpenStream(lpStorage, _T("Contents"), CFile::modeRead|CFile::shareExclusive, &ex))
return FALSE;
CArchive ar(&file, CArchive::load);
平白无故用到了LPSTORAGE这么个类型，还有个常量_T("Contents"), 万一哪天mfc把这个换了，我不是玩完了。
CFile fileLoad(path, CFile::modeRead);
CArchive arLoad(&fileLoad, CArchive::load);
Serialize(arLoad);
arLoad.Close();
fileLoad.Close();
明白了，
我的文档是从COleDocument继承的，可能是这个引起的。不知道前人为什么要从这个来继承呢
假设你的文件是由某个应用程序生成的，该文件中保存了一个CMyClass实例的数据，如果新做的DLL中没有使用CMyClass类，那么它反序列化就会失败，因为它根本不知道如何创建这个类的实例。所以序列化和反序列化必须由同一个模块来完成，不可能分离到一个通用的DLL中。
复合文档的读取也是一样的，但是它不存在把数据恢复成对象的问题，因为CLSID前缀将保证合适的组件被找到并加载，然后把有效数据交给这个组件来初始化。
是有风险的，不过我在dll中不需要创建出类实例，而只需要这个类数据，提取出数据交给其他应用程序使用。
而且最大的麻烦是我的文档序列化有改变时，这个dll也要同步的改变。