最近,我们注意到MFC旧版应用程序中的问题,无论我们在哪里尝试调用Workbook.SaveAs,此调用在使用比我们的开发计算机更旧版本的Office的计算机上都会失败。我认为我已将问题缩小到Excel类型库中的更改,在16.0.4549.1000和16.0.9029.2106之间的某个位置,向SaveAs方法添加了新的可选参数。
但是,我感到困惑的是,为什么这次更改对我们造成了影响,而在过去的10多年中,对类型库所做的类似更改从未发生过。我们使用以下指令进行导入:
// MSO
#import "libid:2DF8D04C-5BFA-101B-BDE5-00AA0044DE52" \
no_dual_interfaces \
rename("RGB", "OfficeRGB") \
rename("SearchPath", "OfficeSearchPath")
// VBA
#import "libid:0002E157-0000-0000-C000-000000000046" \
no_dual_interfaces
// Excel
#import "libid:00020813-0000-0000-C000-000000000046" \
no_dual_interfaces \
rename("RGB", "ExcelRGB") \
rename("DialogBox", "ExcelDialogBox") \
rename("CopyFile", "ExcelCopyFile") \
rename("ReplaceText", "ExcelReplaceText")
据我了解,使用“no_dual_interfaces”可确保通过IDispatch对生成的包装器方法的所有调用,因此使用后期绑定(bind),这应该可以解决类型库中已修改方法的问题。还是我误认为那个假设?
示例代码说明了该问题:
// create Excel instance
Excel::_ApplicationPtr excelApp;
excelApp.CreateInstance(_T("Excel.Application"));
// add a new workbook
Excel::WorkbooksPtr workbooks = excelApp->GetWorkbooks();
Excel::_WorkbookPtr workbook = workbooks->Add();
workbook->Activate();
// insert data
// ...
// save the workbook to the temp directory
TCHAR lpTempPath[MAX_PATH];
GetTempPath(MAX_PATH, lpTempPath);
COleVariant filename(CString(lpTempPath) + _T("ExcelAutomation"));
workbook->SaveAs(filename, vtMissing, vtMissing, vtMissing, VARIANT_FALSE, VARIANT_FALSE, Excel::xlNoChange, vtMissing, VARIANT_FALSE);
我们的SaveAs调用仅提供已受年龄支持的参数,所有较新的参数均保留其默认值vtMissing。无论执行位置使用的是哪个确切的Office版本,我们都期望期望此调用在上述方案中起作用时是否缺少任何内容?
我们直接就此问题与Microsoft专业支持联系,但他们指示我们在StackOverflow上询问...
最佳答案
Microsoft支持服务无法为您提供帮助的事实是可以预期的。他们不会对任何类型的代码进行故障排除。对于此类问题,您需要具有“高级支持”契约(Contract)。
关于c++ - C++ Excel COM自动化-Workbook.SaveAs-找不到成员,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/53630057/