简介：一套基于GDI技术、使用VC++开发的公交线路查询系统源码包，适合学习Windows图形编程与出行路线规划的开发者，也可作为课程设计与毕业设计的参考资料。系统通过GDI绘制站点、线路和地图，支持输入起点终点查询换乘方案，完整覆盖从界面渲染到数据处理的实现流程。压缩包共49个文件，包含15个.h头文件、14个.cpp源文件，以及工程配置（.dsp/.vcproj/.sln）、公交数据（.dat）、说明文档（.txt）和可直接运行的.exe演示程序，总大小4.31MB，目录结构清晰，便于按模块阅读。该项目已有201人浏览学习，可作为GDI自绘控件、C++界面开发及基础GIS应用的实践范例。源码包含站点、线路、路径查找等模块，如XPathFinder、XStation、XLine等，展示了数据加载、GDI渲染、用户交互的完整链路，读者可从中掌握设备无关绘图、自定义UI、公交数据管理及最短路径算法思路，也能通过演示程序直观验证查询效果。
1. 从一份老工程到可运行的公交查询：GDI 与 VC++ 的落地实践
拿到一份标着“基于GDI技术的VC++公交线路查询系统”的压缩包时，大多数人第一反应是双击bus_demo.exe看效果。这个用Visual C++写的Neobus工程，能让你直观看到一条公交线路如何通过GDI画笔一条线一条线画出来，换乘方案如何通过路径查找类绕开转车纠结。它不是炫酷的新框架，而是适合研究GDI绘图、站点建模和经典最短路径的老代码。这篇文章会带你从文件结构、编译运行、数据解析走到避坑细节，最后用双缓冲解决绘制闪烁的问题。如果你手头正好有这份源码，照着做能让它真正跑起来；如果只是好奇老项目怎么设计，也能从类名和文件布局里看出门道。
2. 工程结构拆解：从文件清单看清 GDI 公交系统的骨架
2.1 类文件职责：XSpot、XStation、XLine 与路径查找
拿到压缩包先不要急着编译，花五分钟过一遍文件列表，能少踩一半的坑。NeobusDlg.cpp是主对话框，负责接收起点终点输入和触发查询；XStation.h/cpp对应公交站点，XLine.h/cpp对应公交线路，XSpot.h/cpp对应屏幕上的坐标点，XPassage.h/cpp大概率是换乘通道或线路段，XPathFinder.h/cpp是整个系统最核心的路径查找模块，XTube.h/cpp字面意思像隧道的抽象，在这个场景里可以理解为换乘关系容器。Markup.h/cpp出现得很常见，它是轻量级XML解析类，说明部分数据可能是用XML描述的。
这个结构告诉你一件事：系统没把数据和绘图混在一起写，而是用类把站点、线路、查找逻辑分开。我一般会把每个类对应到一张小卡片，比如XStation成员至少要包括站点编号、站名、线路数量和一个XSpot坐标点。下面这段是典型的站点数据结构定义，你可以对照源码里的XStation.h看差异：
// XStation.h 中常见的站点定义（示范用） struct XStation { int nID; // 站点编号，从0开始 CString strName; // 站点名称，中文或拼音 int nLineCount; // 经过该站的线路数量 XSpot ptPos; // 在GDI画布上的坐标点，单位是像素 };这里XSpot就是坐标的轻量封装，通常只有x和y两个整数。为什么不用stl的pair？因为老项目用MFC习惯自己定义小结构，而且XSpot可以扩展成带路口偏移的复杂类型。写查询算法时，你只需要关心nID和ptPos，strName留给界面显示，nLineCount可以用来判断换乘是否可能：某个站如果只经过一条线路，那必坐这趟车。
2.2 GDI 渲染基础：DC、画笔和坐标变换
GDI是Windows绘图编程接口中最经典的一套。它把显示器、打印机都抽象成设备上下文（Device Context，简称DC），你用同一套函数在屏幕和内存位图上画东西，结果完全一致。公交线路查询系统里最常见的GDI操作是画线、画点、写字。画线之前要准备画笔（CPen），设置颜色、线宽、线型；画点可以用Ellipse画实心圆点。
下面是一段主对话框里绘制多条线路的示意代码，注意先选入新画笔，用完再选回旧画笔：
void CNeobusDlg::DrawNetwork(CDC* pDC) { // 创建蓝色细线画笔 CPen penLine(PS_SOLID, 2, RGB(0, 120, 255)); CPen* pOldPen = pDC->SelectObject(&penLine); for (int i = 0; i < m_Lines.GetSize(); i++) { const XLine& line = m_Lines[i]; for (int j = 0; j < line.m_nStations - 1; j++) { pDC->MoveTo(line.m_ptStations[j].x, line.m_ptStations[j].y); pDC->LineTo(line.m_ptStations[j + 1].x, line.m_ptStations[j + 1].y); } } pDC->SelectObject(pOldPen); }这段逻辑是：外层循环遍历每一条线路，内层循环把该线路的站点依序连接成折线。MoveTo是起点，LineTo画到终点，然后下一次循环从前一个点继续连下去。参数中PS_SOLID表示实线，线宽2像素，颜色是蓝色。SelectObject的返回值是原来的画笔，最后要选回去，否则这个画笔对象在窗口重绘时可能被外部的DC销毁，导致悬空指针问题。
坐标变换是另一个需要留神的地方。GDI以窗口客户区左上角为原点，x向右，y向下。而很多公交数据使用的是经纬度或平面坐标系，y轴方向相反。如果直接把经纬度丢给GDI，线路会变成上下颠倒。常见做法是在数据加载时做一次线性映射，把实际坐标缩放到控件尺寸内，公式是screenX = (rawX - minX) * scale + offsetX，这个可以单独写个函数。
3. 编译与运行：把 bus_demo.exe 之外的代码亲手跑起来
3.1 环境准备与工程转换：从 .dsp 到 .sln
压缩包里同时有Neobus.dsp和Neobus.sln，这是历史上从VC6项目转换为VS解决方案留下的痕迹。.dsp是VC++ 6.0的工程文件，.sln是Visual Studio 2002以后的解决方案文件。如果你用VS2010或VS2015打开Neobus.sln，IDE会提示做一次单向转换，把项目格式更新成当前版本。转换完成后建议不要立即编译，先到项目属性里把字符集改成“使用多字节字符集”。这个项目的代码在Unicode下大概率会报出一堆类型转换错误，原因下一章展开。
我一般不会直接用VS2019或VS2022，因为这些新版本对老MFC工程有更严格的SDK包含规则，容易把时间耗在安装组件上。VS2010、VS2015、VS2017这几个版本打开这个老工程都比较顺。如果你手上只有新版本，也没关系，注意看编译输出里的错误定位，优先修复字符串类型相关的行。
还有一个容易忽略的点：工程属性里“附加依赖项”可能写着旧版库名，比如libcmtd.lib、mfc42d.lib。现代VS找不到这些库，要么改成项目需要的标准MFC库，要么直接在工程配置里删除多余项，让编译器按默认方式链接。最省事的方法是用bus_demo.exe对照功能，代码能编译通过就说明依赖项基本够用。
3.2 数据文件加载：bus_file.dat 与 point.dat 的读取逻辑
程序里出现的bus_file.dat、new_data_.dat、point.dat是三类不同数据文件。从名字看，bus_file.dat保存公交线路的站序和线路名称，point.dat保存站点坐标，new_data_.dat可能是更新后的完整快照。加载逻辑一般在NeobusDlg::OnInitDialog里被调用，文件路径用相对路径“Data”。在IDE里运行时，工作目录默认是项目目录，所以能直接找到；双击exe时工作目录变成exe所在目录，如果Data文件夹不在那里就会失败，这个坑第四章专门讲。
一个健壮的加载函数应该先分解路径，再打开文件。下面这段示范了如何读取站点坐标文件：
BOOL CNeobusDlg::LoadStationPoints(LPCTSTR lpszFilePath) { CStdioFile stf; if (!stf.Open(lpszFilePath, CFile::modeRead | CFile::typeText)) { AfxMessageBox(_T("无法打开point.dat")); return FALSE; } CString strLine; while (stf.ReadString(strLine)) { strLine.TrimLeft(); if (strLine.IsEmpty() || strLine.GetAt(0) == _T('#')) continue; int nID = 0, nX = 0, nY = 0; CString strName; if (_stscanf_s(strLine, _T("%d,%d,%d,%s"), &nID, &nX, &nY, strName.GetBuffer(256), 256) != 4) { strName.ReleaseBuffer(); continue; } strName.ReleaseBuffer(); XStation st; st.nID = nID; st.strName = strName; st.ptPos.x = nX; st.ptPos.y = nY; m_mapPoints[nID] = st; } stf.Close(); return TRUE; }代码里用CStdioFile逐行读文本，跳过空行和#注释行，再把每行的ID、X、Y、名称拆出来。_stscanf_s是安全版格式化输入，返回值是成功匹配的字段个数，必须等于4才认为这一行有效。用到GetBuffer是因为_stscanf_s需要可写字符缓冲区，读完必须ReleaseBuffer，否则字符串对象的内存状态会异常。m_mapPoints用容器保存站点ID到结构体的映射，后续画图和查询都从这个容器取数据。
为什么数据文件不直接用数据库？因为老项目要轻量，一个文本或二进制文件即可随身携带，也方便用手写工具生成。如果你要扩展成真实城市几千条线路的数据，这种加载模式仍然可以用，只是要把内存容器换成链表或更高效的哈希表。
3.3 启动与界面操作：画线路、标站点、查询换乘
编译成功后，运行起来是一个对话框界面。左侧通常有线路列表和查询输入框，右侧客户区是GDI画布。第一次打开会看到所有公交线路以不同颜色绘制出来，站点用实心圆点标记，站名用小号字体放在圆点旁边。点击某条线路，该线路会高亮，可能是加粗或换色。
查询换乘的操作一般是输入起点站名和终点站名，点击“查询”按钮后系统调用XPathFinder，返回路径上的站序列。主对话框会把这条路径用另一支画笔重新绘制，同时弹出文字框列出具体换乘方案。这部分代码要处理好线程阻塞：如果数据量大，路径查找在按钮点击线程里执行会导致界面卡住。常见做法是启用工作线程，查找完成后再PostMessage通知UI刷新。
作为验证，先跑一遍bus_demo.exe，记住它显示的线路条数和站点颜色，再用自己编译出来的exe对比。如果一致，说明代码完整编译正确；如果不一样，多半是数据文件路径没对上或者加载函数提前退出了。
4. 避坑：编译失败、GDI 泄漏与数据路径三大拦路虎
4.1 字符集导致的编译翻车
现象：打开工程一编译，刷出一片C2664错误，说什么“不能将LPCTSTR转换为LPCSTR”，或者“无法从wchar_t转换为char”。
原因：VC6时代默认使用ANSI字符集，项目里的CString和API字符串都是窄字节；而新版Visual Studio默认启用Unicode字符集，LPCTSTR变成宽字符指针，和代码里手写的普通字符串字面量不兼容。
解决：项目属性→配置属性→常规→字符集，改成“使用多字节字符集”。如果代码里塞了很多_T宏，建议干脆统一用_mbs系列函数。改完后批量替换字符串函数为安全版本，比如strcpy换成strcpy_s。实际经验中，这个项目改完字符集后编译错误能减少八成。
提示：改字符集后，记得把字符串函数同步换成安全版本，否则新问题会更诡异。
4.2 GDI 资源泄漏与空白地图
现象：程序运行一会儿后，窗口重绘时出现黑块或空白，甚至直接崩溃；在任务管理器里看GDI对象数持续上涨。
原因：每次WM_PAINT都创建一个新画笔、新画刷，没有删除，也没有选回旧对象。GDI对象有数量上限，Windows回收不及时就会耗尽。我之前在某个图像处理Demo里就犯过这个错误，内存没涨，GDI句柄数却飙到一万多。
解决：在DrawNetwork这类函数里，记住两个不变量：创建对象后立即SelectObject保存返回值；绘制完成后先SelectObject(pOldPen)，再让局部CPen对象销毁。如果代码里用了DeleteObject，不要对仍处于选中状态的画笔调用。双缓冲章节会有更完整的写法。
4.3 数据文件路径的玄学
现象：在VS里按F5运行完全正常，关闭IDE后双击exe却提示“打开bus_file.dat失败”。
原因：进程的工作目录不同。IDE默认把工作目录设为项目目录，你写的是相对路径“Data\bus_file.dat”；双击exe时工作目录是exe所在目录，如果exe不在项目目录，相对路径自然失效。
解决：不要依赖相对路径，启动时用GetModuleFileName获取当前exe完整路径，再截取出目录部分拼接数据路径。代码如下：
CString GetExeDirectory() { TCHAR szPath[MAX_PATH] = {0}; GetModuleFileName(NULL, szPath, MAX_PATH); CString strPath(szPath); int nPos = strPath.ReverseFind(_T('\\')); if (nPos != -1) return strPath.Left(nPos); return _T(""); }然后加载数据时用GetExeDirectory() + _T("\\Data\\bus_file.dat")。注意unicode字符集下路径带TCHAR前缀。另外，如果exe被移动，数据文件夹要跟着移动，否则照样找不到。还有一个细节：Windows Vista以后的UAC可能会拦截写权限，如果程序需要更新数据文件，最好把数据放在用户AppData目录而不是Program Files。
5. 查询算法与数据结构：从换乘规则到路径查找实现
5.1 站点与线路的数据建模
要支持线路查询，光有站点坐标不够。系统至少要回答：从A站出发，我能不能坐某条线到B站；如果必须换乘，换乘发生在哪一站。所以数据结构里必须有线路对象，它内部保存一串有序站点ID。站点和线路是多对多的关系，一个站属于多条线，一条线包含多个站。
常规建模方式有两种：邻接表和邻接矩阵。地铁粒度几百个站用矩阵没问题；公交网络几千个站、几百条线路，矩阵会浪费内存。这个老项目从文件命名看更倾向于用XLines容器装所有线路，运维时遍历线路。我给出的建议是建立两个映射表：一个从站点ID到经过该站的线路ID集合，另一个从线路ID到站点ID序列。这样查询时能用第一个表快速判断换乘可能。
下面是一个简化的数据结构定义：
// 线路与站点关系表（示范） struct XLine { int nLineID; CString strLineName; std::vector<int> vecStations; // 有序站点ID std::vector<XSpot> vecPoints; // 站点对应像素坐标，便于GDI绘图 }; struct XNetwork { std::map<int, XStation> mapStations; // 站点ID -> 站点信息 std::map<int, XLine> mapLines; // 线路ID -> 线路信息 std::map<int, std::vector<int>> mapLineIdsOfStation; // 站 -> 线路列表 };mapStations强调ID检索，mapLines用来绘制和遍历。mapLineIdsOfStation在换乘算法里至关重要：当你站在某个站，想知道能换哪辆车，直接查这个表。
5.2 路径查找算法：默认实现与改进方向
公交路线查询的核心是“最少换乘”或“最短时间”。XPathFinder这个类从名字看就是干这个的。老项目常见实现是广度优先搜索（BFS），因为公交线路图是无权图——换乘一次算一次代价，站数多少可以作为第二目标。BFS能保证找到换乘次数最少的方案，但空间复杂度会随站点数增长。如果你把数据扩到几千条线路，建议升级为带优先队列的Dijkstra或A*，按换乘次数和预计时间计算代价。
下面是一个BFS换乘思路的伪代码框架，你可以在XPathFinder.cpp里对照真实实现：
// 伪代码框架：BFS 搜索最少换乘次数 queue<pair<int, vector<int>>> que; // 当前站点，经过线路ID序列 set<int> visitedStations; que.push({startId, {}}); while (!que.empty()) { auto [curId, path] = que.front(); que.pop(); if (curId == endId) return path; for (int lineID : mapLineIdsOfStation[curId]) { for (int nextStation : mapLines[lineID].vecStations) { if (visitedStations.count(nextStation)) continue; visitedStations.insert(nextStation); auto newPath = path; newPath.push_back(lineID); que.push({nextStation, newPath}); } } }这段逻辑的核心是：每一站向外扩展时，先查看所有经过当前站的线路，再遍历每条线路上所有后续站点，把没走过的站点加入队列。visitedStations避免死循环。注意这里的假设是“在同一线路的任意站点上下车不额外增加换乘次数”，所以路径只记录线路ID。如果你要限制步行距离或考虑方向性，BFS就不够了，得改成带站间距权重的搜索。
另一个改进是用双向BFS，从起点和终点同时扩展，换乘层数较深时能显著减少遍历规模。但双向BFS对代码结构要求更高，老项目很少用，你可以作为进阶实验自己加上。
5.3 结果展示：GDI 如何画出换乘方案
查询命中后，要把结果直观画在地图上。做法是先从path结果里取得线路ID序列，再逐条线路取站点坐标，用醒目颜色（比如红色粗笔）连接成折线，并在换乘站点画一个更大的圆点。绘制时要注意把已经画过的线路擦掉，否则颜色叠加会变成黑团。
关键的刷新逻辑是调用Invalidate(FALSE)，它触发WM_PAINT但不清除背景，这样原地图还在，新画的红色线路覆盖在上面。如果直接用Invalidate(TRUE)会白屏闪烁。这里也顺带说明一下：很多绘制闪屏问题都出在把重绘逻辑写在多个OnPaint分支里，而没有统一用一个绘制函数。
6. 进阶技巧：用双缓冲消除绘制闪烁，扩展城市数据
6.1 双缓冲原理与实现
GDI绘图的闪烁根源在于每次OnPaint都直接画到屏幕上，屏幕刷新的瞬间会看到涂抹过程。解决办法是把所有内容先在内存DC里画好，再一次BitBlt到屏幕。代码结构很简单：
void CNeobusDlg::OnPaint(HDC hDC) { CDC dcScreen; dcScreen.Attach(hDC); // 双缓冲内存DC CDC dcMem; CBitmap bmpMem; CRect rcClient; GetClientRect(&rcClient); dcMem.CreateCompatibleDC(&dcScreen); bmpMem.CreateCompatibleBitmap(&dcScreen, rcClient.Width(), rcClient.Height()); CBitmap* pOldBmp = dcMem.SelectObject(&bmpMem); // 先填充背景 dcMem.FillSolidRect(&rcClient, RGB(255, 255, 255)); // 再把线路画到内存DC里 DrawNetwork(&dcMem); // 一次性复制到屏幕 dcScreen.BitBlt(0, 0, rcClient.Width(), rcClient.Height(), &dcMem, 0, 0, SRCCOPY); dcMem.SelectObject(pOldBmp); bmpMem.DeleteObject(); dcMem.DeleteDC(); }参数说明：CreateCompatibleDC创建与屏幕兼容的内存DC，CreateCompatibleBitmap创建同样尺寸的位图，FillSolidRect先清背景，DrawNetwork在内存DC里执行所有复杂绘制，最后BitBlt整个矩形到位。注意内存DC的画笔、画刷也必须在绘制结束时恢复原状，否则同样的泄漏问题会换种方式出现。从那以后我每次改GDI代码都会强制走一遍这个流程：先检查所有SelectObject有没有成对，再跑一遍双缓冲测试，最后用任务管理器看GDI对象数是否平稳。希望帮到你。
6.2 从 demo 数据扩展到真实公交数据
如果你想把demo换成自己城市的数据，需要按系统约定的文本格式组织站点和线路。最省事的方案是写一个小脚本，把公交车信息导出成系统能读的.dat文件。一般字段顺序为：站点编号，站点名称，X坐标，Y坐标，所属线路编号，线路内站序。注意坐标必须先按窗口尺寸做归一化，否则画出来会跑出边界。我一般会把原始经纬度用墨卡托投影转成平面坐标，再缩放到客户区像素范围。迭代测试时，先导入10条线路看看绘制是否正常，再逐步加量，避免一次导入几万条线路后程序卡死在加载阶段。
6.3 性能验证与调试习惯
扩展数据后的性能不能靠肉眼感觉，我习惯在查询函数前后各加一次QueryPerformanceCounter计时，把查询耗时时长打印到调试窗口。如果超过500毫秒，优先检查visitedStations是否被错误清空，算法是否陷入了重复扫描。还有一个小技巧：把缓存后的GDI画笔、画刷做成对象成员，而不是在每次重绘时重建，可以大幅降低创建开销。
最后说一个我自己的教训：有一次我把线路数据从100条扩到2000条，结果程序启动要半分钟，界面一操作就卡死。排查半天发现是没有做坐标缩放，所有站点都挤在一个角落里，GDI反复画同一个点导致效率极低。从那以后我每次导入新数据都会先渲染一次全图，确认站点分布均匀后再继续调算法。希望帮到你。
本文还有配套的精品资源，点击获取
