简介：这是一套面向 LabWindows/CVI 初学者的 Word 操作例程源码包，重点演示如何借助 ActiveX/COM 技术实现 CVI 程序与 Microsoft Word 的深度交互。例程覆盖创建新文档、设置文本内容与格式、打开已有文档、保存修改以及关闭退出等完整流程，是理解 CVI 外部接口调用与文档自动化的直观样本。压缩包共含 37 个文件，主要文件类型为 C 源代码、头文件、工程文件、工作区文件、用户界面文件，并配有对象库和功能库等辅助文件；按 Word 97 与 Word 2000 两套接口分别组织目录，便于对比不同版本控件调用的差异。整体约 693KB，体积精简，目前已累计 350 人次浏览学习。从该例程中还能学到 Word 对象模型的基本用法、报表生成的封装思路以及测试结果文档化的实现路径，稍加改造即可用于自动输出测试报告或数据归档等实际项目。

1. CVI Word 例程：给测试系统补上自动出报告这最后一环

一套测试系统跑完一轮，几十个指标在界面上跳过了，接下来最磨人的环节是把这些数整理成一份像样的 Word 报告——截图、贴表、调格式，少说折腾半小时。CVI WORD 例程干的事，就是在 LabWindows/CVI 的 C 代码里把这一步自动化：采集完数据，调几个封装好的函数，Word 文档自己生成，标题段落、测试数据表格、波形截图、保存路径全按代码走。它适合所有用 CVI 写上位机的人——产线检测、实验室仪器、自动化测试台，凡是最终要交付 Word 报告的场景，都能拿它当基础模板。核心价值不是「能生成 Word」，而是把报告生成变成测试流程里的一个普通步骤，跟保存一份日志一样顺手。

2. 技术底座与工程骨架：CVI 是怎么和 Word 谈拢的

2.1 三条路里为什么最后选了 ActiveX

在 CVI 里出 Word 报告，常见思路有三条。第一条是直接用fprintf写 RTF 或 HTML 文件，实现最快，但排版能力弱，插图要手工拼<img>标签，表格一复杂就露怯。第二条是生成 CSV 或文本让用户自己贴进 Word，这只能叫「半自动」，测试员照样要动手。第三条就是 ActiveX/COM 直接控制 Word 进程，让 C 代码扮演「操作 Word 的那个人」。

CVI 对 ActiveX 的支持相当成熟：工程里可以加载 Word 的类型库，用自带的 ActiveX Library Generator 把 Word 的 COM 接口生成一堆 C 包装函数，运行时就通过 IDispatch 后期绑定去调。我一般会选这第三条路，原因很朴素——报告格式是业务刚需，排版、表格、图片替换都得可控，而 RTF 那套越写越像在刀刃上跳舞。这个例程走的就是 ActiveX 路线，不需要在目标机器上装额外运行库，只要 Word 本身活着就能用。

2.2 一个典型工程的目录长什么样

拿到的例程解压后，目录结构通常是这样（打包方式不同会略有出入，但核心文件不缺这几样）：

ReportDemo/ ├── report.prj /* CVI 工程文件，双击打开 */ ├── report_main.c /* 入口：造演示数据 + 调用生成 */ ├── report_word.c /* Word 封装层：打开/写内容/存盘 */ ├── report_word.h /* 对外的几个函数声明 */ ├── word_typelib.c /* ActiveX 生成物：Word 对象模型的 C 包装 */ ├── word_typelib.h └── template.docx /* 可选：预置排版的报告模板 */

report_word.c是例程里最值得读的文件，它把 COM 细节全包在里面，外部流程根本不用碰 IDispatch 那一堆接口。word_typelib.c和.h是工具生成的，正常开发不要去手改，重新生成一次就行。template.docx只在模板化改造时才用得上，纯动态生成报告的用法里它可存在可不存在。

2.3 跑通之前先确认三件事

第一，目标机器装了完整版 Word，不是只装了查看器或 WPS 的兼容模式——COM 接口注册表项是完整安装才会有的。第二，CVI 的 ActiveX 支持库没被精简掉，在 CVI 环境里随便调一个 COM 调用能通就说明没问题。第三，位数匹配这件事提前确认：CVI 如果是 32 位，尽量配 32 位 Office，64 位 Office 在部分机器上会调不起来，这一条我放到避坑章细说。

另外有个小习惯，解压路径和工程路径不要带中文。CVI 的字符串是 ANSI 体系，路径带中文进 COM 调用后很容易出现乱码或「文件不存在」这种玄学错误，后面有专门一节讲。

3. 核心模块拆解：从测试数据到 Word 文档的完整调用链

这一章是例程的命根子。下面代码属于示意实现，函数名和 Variant 包装方式以你本机 CVI 的 ActiveX 支持库声明为准，但调用逻辑和顺序是例程通用的。把这条链走通，报告生成就跑起来了。

3.1 打开 Word：CAObjHandle 与 Word.Application 的绑定

所有操作的第一步是拿到 Word 的 COM 接口。例程里一般用一个全局句柄保存，后续所有文档、选区、表格操作都从它身上取：

static CAObjHandle hWord = 0; static CAObjHandle hDocs = 0; int WordReport_Open(BOOL bShow) { HRESULT hr = CA_GetIDispatch("Word.Application", &hWord); if (hr < 0) { LogError("CA_GetIDispatch failed: 0x%08X", hr); return -1; } /* 调试时传 bShow=TRUE，能亲眼看到 Word 在动； 正式流程建议 bShow=FALSE，后台跑不影响界面 */ CA_SetProperty(hWord, "Visible", 0, CAVT_BOOL, bShow); hr = CA_GetProperty(hWord, "Documents", &hDocs); if (hr < 0) { WordReport_Close(); return -2; } return 0; }

CA_GetIDispatch做的是「创建 Word 进程 + 拿到它的 IDispatch 接口」两件事，字符串"Word.Application"是注册表里的 ProgID，换别的 Office 组件同理。第一次调用会悄悄拉起 WINWORD.EXE，这一步大概耗时几百毫秒，所以放到后台线程更稳妥。Visible属性控制窗口显隐，调试阶段建议设成TRUE，你会看到光标自己在动，很有成就感；上了产线就老老实实设FALSE。拿到的hDocs是文档集合，新增文档必须通过它，不能直接凭空创建。

3.2 写标题和段落：Selection 的黑匣子

Word 里有个「光标」概念，COM 里对应 Selection 对象。所有打字动作本质是往光标位置塞内容，塞完光标自动后移。例程里的写法大致是：

static CAObjHandle hDoc = 0; static CAObjHandle hSel = 0; int WordReport_AddDocument(void) { HRESULT hr = CAInvokeMethod(hDocs, "Add", &hDoc, 0); if (hr < 0) return -1; CA_GetProperty(hWord, "Selection", &hSel); CAVariant txt; CA_VariantSetCString(&txt, "某产品出厂测试报告"); CAInvokeMethod(hSel, "TypeText", 0, CAVT_CSTRING, &txt); CA_VariantClear(&txt); CAInvokeMethod(hSel, "TypeParagraph", 0); return 0; }

Documents.Add返回新文档句柄hDoc，Selection从 Word 应用对象上取。TypeText等价于手动敲键盘，TypeParagraph等价于回车。参数CAVT_CSTRING告诉 ActiveX 层「这是个 ANSI 字符串」，需要先装进CAVariant再传。清理用CA_VariantClear，否则内存积累多了也是一个坑。

写长报告时有个血泪经验：纯靠TypeText+TypeParagraph堆段落，段落间距和字体样式会非常松散难看。例程里通常会配合 Font 和 ParagraphFormat 设置字号、加粗、对齐。如果只是演示功能，这些可以不做；真要上生产，建议直接跳到第 6 章的模板方案，别在代码里硬调排版。这属于「代码能跑和报告能看是两回事」的典型差异。

3.3 插测试结果表格：先数行数，再填单元格

测试报告的核心是数据表。Word 的表格模型是Tables集合，添加一张表和逐格填数据是两段操作：

int WordReport_AddTable(const char *headers[], int rowCnt, int colCnt) { CAObjHandle hRange = 0; CAObjHandle hTables = 0; CAObjHandle hTable = 0; CAObjHandle hCell = 0; HRESULT hr; /* 取当前文档全文范围作为表格插入位置 */ CA_GetProperty(hDoc, "Range", &hRange, CAVT_OBJ, 0); CA_GetProperty(hRange, "Tables", &hTables); /* Tables.Add(Range, NumRows, NumColumns) rowCnt 是数据行数，表头单独占一行，所以要 +1 */ CAInvokeMethod(hTables, "Add", &hTable, CAVT_OBJ, &hRange, CAVT_INT, rowCnt + 1, CAVT_INT, colCnt, 0); /* 注意：Word 的行列从 1 开始数，不是 C 数组从 0 开始 */ for (int r = 1; r <= rowCnt + 1; r++) { for (int c = 1; c <= colCnt; c++) { char cellText[128]; if (r == 1) { strncpy(cellText, headers[c - 1], sizeof(cellText) - 1); } else { snprintf(cellText, sizeof(cellText), "%.3f", testData[r - 2][c - 1]); } CAInvokeMethod(hTable, "Cell", &hCell, CAVT_INT, r, CAVT_INT, c, 0); CAObjHandle hCellRange = 0; CA_GetProperty(hCell, "Range", &hCellRange); CA_SetProperty(hCellRange, "Text", 0, CAVT_CSTRING, cellText, 0); CA_FreeObjHandle(hCellRange); CA_FreeObjHandle(hCell); } } return 0; }

Tables.Add接收三个关键参数：插入位置Range、行数、列数。这里最容易踩坑的就是「表头多占一行」和「行列从 1 开始」两个叠加因素——数组习惯 0 起，Word 从 1 起，循环写错一位，表格就会多一行空行或者少一列数据。逐格填充用Cell(r, c).Range.Text，这个调用嵌套了两层属性，用完记得逐层释放句柄。参数headers是表头字符串数组，testData是二维数组，具体数据来源按你的测试项目替换。

3.4 插入波形截图：图片路径必须绝对、必须干净

测试报告不加图总感觉缺了灵魂。CVI 配套的波形图控件导出 PNG 后，用InlineShapes.AddPicture塞进文档：

int WordReport_InsertImage(const char *pngPath) { CAObjHandle hInShapes = 0; CAObjHandle hRange = 0; CA_GetProperty(hDoc, "InlineShapes", &hInShapes); CA_GetProperty(hDoc, "Range", &hRange, CAVT_OBJ, 0); /* InlineShapes.AddPicture(FileName, LinkToFile, SaveWithDocument, Range) LinkToFile=0 表示嵌入，SaveWithDocument=1 表示图片随文档保存 */ CAInvokeMethod(hInShapes, "AddPicture", 0, CAVT_CSTRING, pngPath, CAVT_BOOL, 0, CAVT_BOOL, 1, CAVT_OBJ, &hRange, 0); }

两个参数值得多看一眼。LinkToFile为 0、SaveWithDocument为 1，意思是图片内容直接写进 docx 文件，不依赖外部图片路径——否则你把这个 docx 发给别人，图就裂了。pngPath必须是绝对路径，相对路径在某些 Office 版本下会莫名失败。我一般先在程序里把截图存到C:\Temp\report_xxx.png这种全英文临时目录，再调这个函数，省掉中文路径的乱码隐患。

3.5 保存、关闭、退出：释放顺序决定你有没有残留进程

写完内容最后收尾，顺序极其重要：

void WordReport_Save(const char *filePath) { CAVariant vPath; CA_VariantSetCString(&vPath, filePath); /* SaveAs2(FileName, FileFormat)，16 表示 docx 格式 */ CAInvokeMethod(hDoc, "SaveAs2", 0, CAVT_CSTRING, &vPath, CAVT_INT, 16, 0); CA_VariantClear(&vPath); } void WordReport_Close(void) { if (hDoc) { CAInvokeMethod(hDoc, "Close", 0, CAVT_BOOL, 0, 0); CA_FreeObjHandle(hDoc); hDoc = 0; } if (hDocs) { CA_FreeObjHandle(hDocs); hDocs = 0; } if (hWord) { CAInvokeMethod(hWord, "Quit", 0); CA_FreeObjHandle(hWord); hWord = 0; } }

Close先关文档，Quit再退 Word 应用，最后CA_FreeObjHandle释放 COM 引用。顺序反了，WINWORD.EXE就会常驻任务管理器，删都删不掉。句柄置零是个好习惯，WordReport_Close变成可重入函数，重复调用也不崩。文件格式参数 16 对应 docx，如果目标环境是老旧 Word，改成 0 存成 doc 格式也兼容。保存路径同样建议全英文，这一条在很多人的现场翻过车。

4. 避坑记录：Word 自动化里最常见的五个事故现场

4.1 WINWORD.EXE 一直残留，任务管理器一片 Word 进程

现象：程序跑完一轮，任务管理器里多了好几个 WINWORD.EXE，越跑越多，最后系统变卡。

原因：Quit之后 COM 句柄没有释放，或者文档没关就急着退出。Word 的 COM 对象是计数管理的，句柄不清零，进程认为还有人引用它，就赖着不走。

解决：严格按「关文档 → 退应用 → 释放句柄」的顺序收尾，WordReport_Close里每个CA_FreeObjHandle之后立即置空。如果程序异常退出导致残留，先杀进程再改代码，别指望 Office 自己清理。

4.2 换一台机器就报「未注册」或自动化错误

现象：在自己电脑上跑得好好的，拷到另一台机器，一调CA_GetIDispatch就失败，错误码指向REGDB_E_CLASSNOTREG。

原因：CVI 生成 Word 类型库时，把当时机器上 Office 版本的 GUID 写死了。目标机的 Office 版本或语言包不一样，GUID 对不上，类就没注册。

解决：在目标机上用 ActiveX Library Generator 重新生成一遍word_typelib.c和.h。如果不想折腾，干脆改成纯后期绑定，不依赖类型库，直接拿"Word.Application"ProgID 走 IDispatch，这样换机器最省心。例程里两种写法都有，看你的部署环境决定。

4.3 32 位 64 位不对付，接口调不通

现象：开发环境能跑，部署到某些新配的电脑上，报告功能静默失败，没有弹窗。

原因：常见组合是 32 位 CVI 配了 64 位 Office。COM 跨位数调用在部分系统环境下就是不行，Office 的 COM 注册表项在 64 位系统里有独立重定向，32 位进程找半天找不到。

解决：最省事的办法是目标机装 32 位 Office，工控机器一般没人在意 Office 自身位数。要是没法换 Office，就得确认你的 CVI 环境是否有 64 位版本、项目能否迁移。排查时打开组件服务看 DCOM 配置里的 Word 项，位数和账户配置不对劲都会导致静默失败。

4.4 中文内容或中文路径乱码

现象：报告里中文标题变成一串问号，或者指定保存到D:\测试报告\时报「文件未找到」。

原因：CVI 的字符串是 ANSI 编码，Word 的 COM 接口期望 Unicode（BSTR）。中间 Variant 转换时如果代码页对不上，中文就废了。路径乱码则是文件系统层 ANSI 转 Unicode 的经典事故。

解决：路径强制全英文，文件名用时间戳或序号拼，这是最稳的。中文内容尽量通过 BSTR 相关接口传入。如果例程里用的是CA_VariantSetCString，在中文环境下建议手动转成宽字符再CA_VariantSetWString。这个问题在中文版 Windows 上几乎必现，别抱侥幸心理。

4.5 表格行列对不上，数据错位

现象：生成的表格多了一行空行，或者最后一列的数据跑到表头里去了。

原因：Word 表格行列从 1 开始，C 数组从 0 开始。循环里用r <= rowCnt而不是r < rowCnt + 1，就会漏掉最后一行；表头那行没单独处理，数据就跟表头错位了。

解决：写表格循环前先明确两个数字：总行数 = 数据行数 + 1（表头），循环从 1 到总行数。填充单元格时用headers[c - 1]做表头索引，数据用data[r - 2][c - 1]，这样一进一出基本不会错。改完先拿三行两列的假数据跑一遍，肉眼验完再上真实数据。

5. 从例程到集成：把报告生成塞进 CVI 多线程流程

5.1 为什么不能直接放 UI 线程

例程在演示时通常直接按钮回调里调WordReport_Open，但上真实系统就不行了。Word 启动加保存，快则几百毫秒，慢则两三秒，如果还要往文档里插五六张波形图，整个界面直接冻结。用户第一反应是再点一次按钮，结果开了两个 Word 实例在抢文件，翻车现场就是这么来的。常见做法是丢进后台线程，界面照常转。

5.2 worker 线程的最小骨架

CVI 里可以用线程池函数，也可以用朴素的CreateThread。关键是线程内部要自己初始化 COM：

typedef struct { char outPath[260]; double *data; int dataCnt; } ReportTask; static void ReportWorker(void *arg) { ReportTask *t = (ReportTask *)arg; /* worker 线程必须自己初始化 COM，否则 CALLBACK 直接失败 */ HRESULT hr = CoInitialize(NULL); if (hr >= 0) { WordReport_Open(0); WordReport_AddDocument(); WordReport_AddTable(g_headers, t->dataCnt, g_cols); WordReport_InsertImage("C:\\Temp\\wave_1.png"); WordReport_Save(t->outPath); WordReport_Close(); CoUninitialize(); } free(t->data); free(t); }

CoInitialize是 COM 的 apartment 初始化，主线程可能已经初始化过，但 worker 线程是独立天地，不调就等着调用失败。所有WordReport_系列函数必须在同一个线程里做完，那些static CAObjHandle不能跨线程共享——COM 对象和初始化它的线程有绑定关系，跨线程用会直接崩掉。任务投递之后主线程不要碰t->data，所有权已经转移给 worker 了。

5.3 和采集流程的配合方式

采集完成后打包任务是最顺的衔接：采集线程把一轮结果深拷贝进ReportTask结构体，投递到后台，采集立刻开始下一轮，两边互不阻塞。报告生成完要通知界面，用 CVI 的PostMessage或者设一个完成标志都行。这里有个新手易犯的错误——直接传全局缓冲的指针给 worker，下一轮采集马上覆盖了这份数据，报告里全是同一份数。任务里的数据必须深拷贝，宁可多花一点内存，也要保证报告是当时那一轮的快照。

6. 二次开发：用 Word 模板 + 书签填充替代硬编码排版

6.1 模板和书签的工作方式

硬编码排版的痛点是改格式要动代码。二次开发时我习惯先做一份template.docx：在需要填标题、插表格、放图片的位置，用 Word 的「插入 → 书签」功能埋好标记，命名成bm_title、bm_table、bm_image。代码不再用一堆TypeText敲排版，而是定位书签、填内容：

CAObjHandle hBmks = 0, hBm = 0, hRange = 0; CA_GetProperty(hDoc, "Bookmarks", &hBmks); CAInvokeMethod(hBmks, "Item", &hBm, CAVT_CSTRING, "bm_title", 0); CA_GetProperty(hBm, "Range", &hRange); CA_SetProperty(hRange, "Text", 0, CAVT_CSTRING, "某产品出厂测试报告", 0);

这样排版全在 Word 里解决，代码只做数据映射。换格式只需要改模板，C 代码一行不用动。

6.2 书签被吃掉的问题和验证习惯

有一个坑要提前说：对书签的Range.Text赋值后，书签本身会被替换掉，同一份模板第二次跑就找不到bm_title了。稳妥做法是替换前记住书签名，替换后用Bookmarks.Add把书签补回去，或者只在书签后面做追加插入。我自己的验证习惯是：生成一版后手工打开，用「查找书签」逐位置检查；再脚本批量生成几十份，抽查文件大小和页数有没有异常。从那以后，我每次接到「出报告」的需求，都先让需求方落一份模板再写代码，排版问题在 Word 里解决，代码里只留数据映射。希望帮到你。

本文还有配套的精品资源，点击获取