简介陈建春《用Visual C开发GIS系统》的配套代码包专为学习VC与MFC的初学者设计用于通过实际工程掌握图形编程、界面搭建和GIS基础开发。代码基于MFC框架完整呈现了文档/视图结构、GDI绘图、对话框交互等关键知识点适合对照书籍逐步阅读和调试。压缩包共90个文件以cpp源码、h头文件和bmp位图资源为主另有rc资源脚本、mdb示例数据库及帮助文档等整体仅144KB便于快速下载和浏览。已有303人学习不少读者借此入门MFC但需注意该示例偏重教学演示缺少大型地理数据管理、空间索引、投影转换等实用GIS能力更适合作为图形系统开发的起步参考。通过研读代码能够直观理解地图要素如何绘制、菜单工具栏如何组织以及程序框架如何运行为后续接触GDAL、ArcObjects等专业GIS开发打下基础。1. 为什么说这套Visual C GIS配套代码仍是稀缺的实战资产一套二十多年前随教材一同发布的Visual C GIS系统配套代码放在今天依然能让新手少走三个月弯路这不是怀旧而是这套代码把矢量GIS的骨架完整地搭了出来。很多从业者第一次真正理解图层、要素、坐标转换和MFC文档视图架构不是靠教材文字而是靠把这套代码编译起来、打断点、逐行走读。它能解决的实际问题很明确想从零搭一套能显示、能查询、能编辑的基础GIS框架或者被老系统拖住、急需弄懂旧架构的维护者。适合两类人刚入行想做GIS开发的C程序员以及被历史代码困住、需要迁移或二次开发的人。花两周把它读通比零散看十篇教程都值。2. 源码包长什么样目录结构、核心类与一条数据的完整旅程2.1 拿到源码先认目录dsw/dsp工程与六个功能模块解压配套代码后第一眼看到的是一堆后缀为dsw和dsp的文件。dsw是VC6的工作区文件一个工作区里可以挂多个工程dsp是单个工程的工程文件。这套代码一般会拆成几个子工程一个基础库工程存放通用数据结构和算法一个或几个应用工程存放界面和业务流程。这样组织的直接好处是基础库可以单独编译成静态库主程序出问题时不至于牵连全局。常见的目录划分大致如下表目录或文件常见内容说明.dsw / .dsp工作区与工程定义决定编译顺序和依赖关系Src 或 Source各模块的.cpp与.h核心代码基本都在这里Res对话框、图标、菜单资源界面资源的定义与位图Data 或 SampleData示例地图数据用来验证显示和查询功能Output 或 Debug编译产物通常会在首次编译前清空打开dsw文件后VC6会按工作区里的工程依赖关系自动排序。我的习惯是先不急着按F7编译整个工作区而是逐个展开工程节点看依赖关系。很多翻车现场都是因为直接编了整个工作区基础库还没编出来主程序链接时疯狂报无法解析的外部符号。先认清哪个是基础库、哪个是主程序比什么都重要。2.2 对象模型是整套代码的灵魂图层、要素、渲染三分层这套代码最有学习价值的不是某个算法而是它的对象模型。用今天的眼光看它天然贴合数据与显示分离的原则。核心可以抽象成三个角色图层对象管理空间范围与数据来源要素对象表示一个具体的点、线或面渲染对象负责把要素画到屏幕上。图层持有要素集合渲染器按图层的显示风格遍历要素并绘制三者各管一段。这套设计的巧妙之处在于要素不关心自己长什么样图层把数据和显示隔离开。比如要换一种符号去画路网只需要改渲染器的绘制参数不需要动要素对象。这对后来的扩展特别重要新增一种数据格式时只要让数据解析部分产出标准要素对象渲染层几乎不用改。很多现代GIS框架的架构思路本质上和这套老代码是同一个方向。还有一个值得反复看的细节坐标是放在要素里还是放在字段里。这套代码的做法通常是把几何坐标单独封装在几何对象里属性数据放在另一个集合里两者通过要素ID关联。这个设计直接影响了后续做空间查询的性能。如果当初为了省事把坐标和属性揉在一起后面做空间索引就非常被动。2.3 一条数据从磁盘到屏幕的完整链路理解了对象模型再看数据是怎么从文件变成屏幕上的图形就顺了。以最常见的文本数据加载为例流程是打开文件、按行解析、每行构建一个要素对象、加入图层、图层计算外包矩形、触发视图重绘。下面这段代码把这套流程最核心的部分抽了出来// 从文本数据文件读取点要素构建内存图层并触发重绘 // 这是配套代码里最常见的一类数据加载流程 bool LoadLayerFromTextFile(CLayer* pLayer, const char* szPath) { FILE* fp fopen(szPath, r); // 老式C文件接口VC6下最稳定 if (fp NULL) return false; char szLine[512]; while (fgets(szLine, sizeof(szLine), fp)) // 按行读避免一次读大文件撑爆内存 { double x 0.0, y 0.0; // 坐标值必须用双精度单精度会丢精度 int nType 0; // 要素类型0点 1线 2面 if (sscanf(szLine, %d %lf %lf, nType, x, y) ! 3) continue; // 脏数据行直接跳过不让它中断整个图层 CFeature* pFeat new CFeature(nType); // 一行对应一个要素对象 pFeat-SetPoint(x, y); pLayer-AddFeature(pFeat); // 图层持有要素集合 } fclose(fp); pLayer-ComputeBounds(); // 由所有要素算出图层外包矩形 AfxGetMainWnd()-Invalidate(); // 触发视图重绘走OnDraw return true; }这段代码的逻辑说明函数先打开文件逐行读取并把坐标和类型解析出来解析失败的行直接跳过避免一条脏数据毁掉整个图层。每个要素对象被new出来之后交给图层管理最后通过ComputeBounds计算图层的经纬度或平面坐标范围这个范围在后续缩放和居中显示时就是全局参照。参数说明sscanf的第三个参数是坐标值这里强制用double接收因为单精度float在在几百公里的坐标范围下会累积明显误差nType这个参数直接决定渲染器用点、线还是面的画法来绘制该要素所以这个值必须在前面就约定好和渲染器的分支判断保持一致。最后那个Invalidate很关键如果去掉程序把数据读完但界面不会刷新看起来就像没加载成功。3. 在VC6里跑通配套代码编译设置与最小启动步骤3.1 环境准备VC6本体、SP6补丁与MSDN缺一不可这套代码的设计年代对应Visual C 6.0配套工程格式是老的dsw/dsp新版本Visual Studio虽然能勉强打开但转换过程会引入大量差异甚至直接丢失工程配置。所以第一步不是迁到新环境而是老老实实装一个VC6。装好之后一定要打SP6补丁否则调试器在Windows较新版本上经常附加失败。MSDN在当年的作用不只是查API它包含了完整的MFC类层次图和消息流说明。读这套代码时一半的时间要花在查MSDN上。如果你手头没有当年的MSDN光盘用现代搜索引擎查MFC类接口也能凑合但要小心版本差异很多老接口的备注在新文档里被改写了。安装位置也需要注意。VC6对中文用户名和带空格的路径支持有问题工作区路径里一旦有中文编译时可能莫名报Error spawning cl.exe。我一般直接装在C盘根目录工程也放在C:\GisSrc这种纯英文路径下省掉一整套玄学问题。3.2 编译顺序先基础库后主程序别一上来就F7VC6的工作区支持多个工程Common或Base这种基础库工程会产出静态库文件主程序工程依赖这些静态库。如果直接对整个工作区执行BuildVC6一般会自动按依赖顺序编译但前提是依赖关系配置正确。判断方法很简单右键工作区根节点查看工程依赖列表确认主程序勾选了基础库工程。更稳妥的做法是手动分两步。先单独编译基础库工程确认静态库文件生成成功再编译主程序。这样链接阶段报错时能快速定位是库的问题还是主程序代码的问题。编译选项里有三个关键项一定要确认工程属性推荐取值说明C/C语言标准默认不带 /Za老代码大量使用微软扩展语法运行时库Debug版用Debug Multithreaded避免运行时库冲突字符集多字节字符集老代码普遍用char而非wchar_t这三个设置里最容易出问题的是第三个。VC6默认的多字节字符集和老代码里的char数组完全匹配如果误设成Unicode所有CString和char混用的地方全会编译失败。基础库编过了主程序还报错时先回头看一眼是不是动过字符集。3.3 最小启动步骤打开、编译、加载数据、交互环境就绪后最小启动路径是四步打开dsw工作区编译基础库编译主程序运行。运行起来后先不要急着点工具栏找菜单里的打开图层或加载数据入口选择SampleData目录下的示例数据文件。能正常显示并支持缩放、平移说明整套代码已经跑通。下面这段代码反映了主程序加载一个图层的典型调用序列理解了它菜单里那个按钮背后发生的事就清楚了// 主程序挂接图层的核心逻辑建图层、加载、设置样式、刷新 CMapDoc* pDoc GetDocument(); // MFC文档对象持有所有图层 if (pDoc NULL) return; pDoc-RemoveAllLayers(); // 先清空旧的避免叠加污染 CLayer* pBase new CLayer(base); // 第一个参数是图层标识名 if (pBase-LoadFromFile(_T(data\\base.shp))) { pDoc-AddLayer(pBase); // 加入成功后文档接管所有权 } else { delete pBase; // 加载失败必须释放否则内存泄漏 } CLayer* pRoad new CLayer(road); pRoad-SetRenderStyle(1, RGB(255, 0, 0)); // 线型渲染红色 if (pRoad-LoadFromFile(_T(data\\road.shp))) pDoc-AddLayer(pRoad); pDoc-UpdateAllViews(NULL); // 通知所有视图刷新显示这段代码的逻辑说明先拿到当前文档对象清空旧图层避免重复叠加然后逐个加载数据文件。这里的LoadFromFile是关键入口它内部把文件解析成要素并计算边界。AddLayer之后图层的生命周期归文档管理所以加载失败的图层要手动delete否则每次重新打开文件都会泄漏一块内存。参数说明SetRenderStyle的第一个参数是几何类型编码1通常表示线状要素第二个参数是颜色值。写死RGB(255,0,0)只是演示实际工程里一般从配置或图例中读取。UpdateAllViews的作用是让所有关联视图同步重绘如果你的程序里有鹰眼窗口之类的小视图这句话也能让它们同步刷新但不能把Invalidate和UpdateAllViews混为一谈前者是刷新请求后者是直接派发重绘消息。4. 把代码迁到高版本Visual Studio三个必改点与一套验证方法4.1 字符集切换与老C运行库API替换把配套代码从VC6迁到Visual Studio 2015或更高版本时编译器会先用铺天盖地的C4996警告和错误迎接你。根源是两个VC6默认的字符集是ANSI多字节新版默认是Unicode另外很多老C运行库函数在新版编译器中默认触发安全警告凡是fopen、sprintf、strcpy这类函数全部中招。最省事的方案是保持工程字符集为多字节并在工程预处理定义里加一个_CRT_SECURE_NO_WARNINGS把安全警告关掉。但这不是长久之计。若要真正在新版本上稳定维护建议把数据解析这类与界面无关的代码切换为标准C风格// 迁移到VS2015以上版本时老C运行库API会直接报编译错误 // 改造前fopen 在VC6下没问题在VS2015默认编译环境直接C4996 FILE* fp fopen(szPath, r); // 改造方式一用带安全校验的版本注意参数顺序变了 FILE* fp NULL; fopen_s(fp, szPath, r); // 第一个参数要传指针地址不是直接返回值 // 改造方式二切到C流更推荐自动管理生命周期 std::ifstream in(szPath); if (!in.is_open()) return false;这段代码的逻辑说明fopen_s把文件指针的地址作为第一个参数传入函数内部负责分配和赋值返回值是错误码。相比fopen直接返回指针这种方式能保证指针被安全初始化也不容易写出忽略打开失败的代码。而std::ifstream用起来更省心出作用域自动关闭文件少一个fclose也少一个泄漏点。参数说明fopen_s第一个参数传的是指针的指针新手最容易在这里翻车写成了fp而不是fp编译能过但运行直接崩溃。如果你决定保留fopen这种老接口在工程属性预处理定义里加上_CRT_SECURE_NO_WARNINGS可以让警告消失但我不推荐把这个宏当长期方案它会把真正该修的隐患也一并遮掩了。4.2 消息映射与MFC头文件的版本差异老代码用MFC 6.0的文档视图架构新版本MFC整体变化不大但细节差异足够让代码编译失败。第一个常见的坑是for循环作用域。VC6的编译器允许在for循环里声明的变量在循环外继续使用而新版编译器把变量作用域严格限制在循环体内。原代码如果写成下面这种风格迁移后必然报错// 老代码常见写法VC6下编译通过VS2015直接报未定义标识符 for (int i 0; i pDoc-GetLayerCount(); i) { // 循环体 } // 这里继续用 iVC6允许新版不允许 if (i pDoc-GetLayerCount()) // 编译错误解决方式是在循环外声明循环变量把int i提前到使用处。机械替换不难但数量多我一般用编辑器批量搜索规律把for (int i替换成int i; for (i的模式这样处理后代码风格也更符合现代规范。第二个差异在CString。VC6时代的CString能隐式转换成const char*新版CString类模板不再允许直接转换必须调用GetBuffer或者用CT2A这类转换宏。配套代码里凡是直接把CString传给FILE或char函数的地方迁移时会集中爆炸。最省力的方法是把数据层函数签名里的CString参数改成std::string或const char*界面层保留CString做显示这样数据层就不用反复做转换效率也能提上去。4.3 迁移后怎么验证功能没改坏显示、查询、编辑三层验证迁移完成的标准不是编译零错误而是功能行为和原来一致。我一般按三层验证框架逐项过每一层都直接对应配套代码的核心能力。显示层验证是最基本的查询层检验对象模型有没有被破坏编辑层验证数据回写链路是否仍然完整。验证项操作方式预期结果显示层加载示例数据缩放、平移、全图图形无偏移、无闪烁、图层顺序正确查询层点击一个要素查看属性表属性与图形能对上中文不乱码编辑层新增一个点要素并保存重新打开文件后新要素仍在坐标一致性切换两种不同范围的数据集视图能自动按外包矩形适配这套验证里最容易走形式的是坐标一致性检查。很多迁移工程只拿一个小数据文件测显示看起来一切正常等到换成城市级的大范围数据偏移、错位、显示不全全跑出来了。我习惯在验证表里固定放一个大范围数据集和一个小范围数据集两组数据都要能正确显示才算真正过了显示层这一关。查询层的验证一定要做交叉检查选要素、看属性、再按属性定位要素双向都对得上才算合格。5. 避坑排查编译报错、乱码与数据错位的四个关键教训5.1 坑一一编译就报几百个错误链接器列出一串无法解析的外部符号现象工作区编译进行到一半主程序链接时报错提示LNK2001或LNK2019一大堆外部符号无法解析看起来像源码缺失。原因绝大多数情况是基础库工程没有成功编译或者基础库和主程序的运行时库设置不一致。链接器找不到静态库中的符号于是把所有相关符号全部列出来吓唬人。还有一部分原因是工程依赖关系配置丢失主程序没有自动触发基础库编译。解决先单独编译基础库工程确认生成静态库文件。再看主程序的工程设置链接里有没有把基础库的.lib文件加入附加依赖。最后检查两个工程的运行时库设置是否一致Debug版统一用Debug MultithreadedRelease版统一用MultithreadedDebug版混用Release库是这类问题的第二大来源。5.2 坑二属性表中文乱码数据能用但界面全花现象地图图形显示正常属性表里的中文字段全部变成问号或乱码甚至对话框按钮上的中文也一起花掉。原因字符集混乱。老代码的资源文件是GB2312编码编译时代码页用的是本地中文系统代码页一切正常。迁移后工程字符集被改成Unicode资源加载和CString转换方式都变了老代码里char数组承载的GB2312字节流和新界面的Unicode转换规则对不上界面就花了。解决如果工程还留在VC6环境检查工程设置的字符集确实为多字节。如果已经迁到新版本把界面中文通过资源编辑器重新保存为Unicode资源并规范字符串转换路径凡是进入界面显示层的字符串统一转成CString脱离界面层统一转成UTF-8或GBK。最忌讳的是有的地方传char*有的地方传CString两边互相混着用乱码只是时间问题。5.3 坑三地图显示偏移半个屏幕坐标系和显示范围没对齐现象点要素位置整体偏到视图的一侧或者图形发生了上下颠倒缩放后要素跑到了完全无关的位置。原因配图上最常见的两类错误。一类是数据本身有地理坐标而显示视图按平面直角坐标处理没有做投影转换经纬度直接当平面坐标用在高纬度地区看起来就会扭斜。另一类是视图的显示范围与图层外包矩形没有联动加载新图层后没有更新显示范围老视图参数套用了新数据看起来就像整体偏移。解决加载完所有图层后重新计算所有图层的并集边界把视图显示范围强制设置到这个并集边界上。配套代码中通常会有ZoomToExtent或类似功能调用顺序一定是加载完数据再执行不能反过来。如果数据本身是经纬度要确认渲染坐标转换是否经过墨卡托或高斯克吕格投影没有投影转换就直接用double承载经纬度做屏幕映射错位是必然的。5.4 坑四一遇到大文件就闪退程序没有任何报错直接消失现象小数据文件一切正常一旦加载整个城市级别的数据程序运行几秒后直接闪退没有弹窗没有异常提示调试器里也看不出明显原因。原因老代码的内存管理普遍粗糙。一个典型问题是每读一条要素就new一个对象小文件看不出问题大文件频繁分配小块内存导致内存碎片严重长时间运行后分配失败。另一个典型问题是栈上开了大数组把几百KB或几MB的数据直接定义成局部变量栈空间被耗尽程序在毫无征兆的情况下就被系统终止了。解决把大批量要素改成分批次读取读到一定数量先入图层再继续避免一次性在内存里挂满几十万个要素对象。凡是超过64KB的缓冲区一律从栈上移到堆上用new或std::vector管理。排查时打开调试器的异常设置把访问冲突和堆损坏相关的异常全勾上重新跑一次大文件通常能直接定位到问题代码行。真正治本的做法是引入空间索引按格网分块管理要素但这属于后续改造不在这次排查范围内。6. 把配套代码变成自己的GIS脚手架一条可复用的改造路径跑通原版代码只是第一步更聪明的用法是把它改造成自己的脚手架。改造路径分两步先把数据读取抽象成接口再为每种数据格式各写一个实现。抽象的关键是让上层只依赖接口不依赖具体格式解析。这样将来接PostGIS或GeoJSON上层一个字母都不用改。// 把底层数据读取抽象成接口后续接新格式只加实现不动上层 class IGisDataSource { public: virtual ~IGisDataSource() {} virtual bool Open(const char* szPath) 0; // 打开数据源 virtual bool ReadNextFeature(CFeature feat) 0; // 读取下一个要素 }; class ShpDataSource : public IGisDataSource { // 按shapefile规范记录头坐标块逐条读 }; class TxtDataSource : public IGisDataSource { // 按文本格式一行一个要素 };这个接口的价值在于ReadNextFeature一次只读一个要素上层可以边读边放入图层配合进度条做到流式加载也让大文件场景下的内存压力大幅下降。改造时我养成的一个习惯是每次动核心类前先给原版代码做一份基线编译然后把所有改动记录在一个单独的diff清单里。这条习惯帮我避开过好几次深坑——改到一半想回头确认原逻辑时直接对照清单就能定位不用靠记忆复原。如果你刚拿到这套代码建议顺序是先读对象模型再跑通编译然后走一遍数据加载链路最后才谈改造。跳过前两步直接动手改踩坑概率会成倍上升。这套老代码最好的归宿不是躺在光盘里吃灰而是作为你理解GIS系统骨架的第一块跳板希望帮到你。本文还有配套的精品资源点击获取