简介使用PowerBuilder开发的高拍仪与摄像头应用源码直接面向需要快速搭建证件照拍摄、二维码识别等桌面功能的软件开发者和系统集成商。源码实现摄像头实时图像采集、证件照尺寸与背景处理、OCR文字读取、二维码解码等核心能力并兼容PB 9、11.5和12.5多版本方便在不同开发环境中复用。压缩包共190个文件大小约89.71MB主要包含pbl、pbd工程源码dll运行库xml配置jpg、png图片素材exe演示程序以及修改日志等目录结构清晰便于按需提取。目前已有175人学习下载借助这套源码可以直观理解PowerBuilder如何通过API与摄像头交互、集成OpenCV等视觉库掌握数据窗口与底层设备协同开发的典型实现思路大幅节省同类项目的调研与联调时间附带的多版本工程与修改日志还能帮助开发者对比差异、追溯迭代过程适合作为图像采集与识别模块的改造蓝本。 很多年前我第一次听到用PB写高拍仪这个需求时第一反应是这玩意儿不是应该用C#或者Delphi写吗后来真进了现场才发现政务窗口那一排排老客户端十个里有七个是PowerBuilder写的高拍仪、身份证阅读器、二维码扫码枪全都得往这个老骨架里塞。今天想聊的pB源码高拍仪本质就是这么一件事在PB程序里把摄像头调起来拍证件照、扫描单证、识别二维码然后把采集到的数据接进现有业务流程。这个需求在窗口办事、柜台受理、档案电子化这类场景里太常见了。工作人员点一下拍照摄像头实时预览再点一下采集身份证或驾驶证就落到系统里如果证件上有二维码最好还能自动识别出来把号码填进表单。整个过程看起来没什么技术含量但真正把预览、抓帧、图片转换、二维码识别、数据窗口回显串起来并且做到连续跑一整天不崩坑其实不少。这篇文章就从选型开始把一条能落地的完整链路拆开讲清楚。1. 为什么到现在还有人用PB写高拍仪先说点实际的。很多业务系统是十几年前用PowerBuilder 9或者PB11写的数据库连的是Sybase或Oracle前端逻辑、审批流、打印模板全在里面重新用别的语言改写一轮成本高到没人愿意立项。这种情况下高拍仪这种新外设就只能嵌进老PB客户端里。所以不是PB适合干这个而是业务系统已经在这里外设必须迁就系统。一个典型的高拍仪客户端要完成的事情比想象中多。首先是视频预览让操作员看到镜头当前的画面然后是单帧抓取把画面定格成图片接着是图片处理裁剪、压缩、转成JPG归档再往后是内容识别比如二维码里存的证件号码、单据编号。如果是带副镜头的高拍仪一体机还要处理主摄像头拍文档、副摄像头拍人像的切换逻辑。这些功能单拎出来Windows自带的能力和第三方库都能做难点在于PB这个壳。它的生态早就停滞了很多新库没有官方绑定调用摄像头只能走API或外部进程图像处理也得绕路。但也正因为这样一旦你趟出了一条稳定路径这套代码能安安静静跑很多年。我这套方案在多个窗口项目上验证过核心逻辑基本没改过换的无非是摄像头型号和安装环境。2. 技术路线PB调用摄像头的三条路先说结论PB调摄像头没有银弹只有三条相对成熟的路选哪条取决于你手里的设备是什么、识别需求有多重。2.1 厂商SDK/OCX省事但绑定设备良田、华通、紫光这些高拍仪厂商大多会提供自己的SDK里面有预览、拍照、连拍、条码识别这类封装好的接口有些还带ActiveX控件可以直接拖进PB窗口里用。走这条路最省事尤其是厂商把副摄像头、补光灯、自动对焦都封装好之后程序代码量会小很多。但缺点是绑定太死。换了厂商或换型号SDK接口可能变代码要重新适配。更痛苦的是有些厂商只提供C#或Delphi的示例PB的例子压根没有你得自己用OLEObject去调用控件接口遇到文档缺失的地方全靠猜。还有一点老型号高拍仪的SDK识别能力普遍一般二维码识别率不如专用库如果对识别准确率要求高纯靠厂商SDK不一定够用。2.2 avicap32.dll底层原生自己动手这是Windows从老多媒体时代留下来的视频捕获接口PB通过声明外部函数可以直接调用不依赖任何厂商驱动。优点是通用性极强几乎所有USB摄像头都能认代码量也控制得住缺点是只解决取流和抓帧图像处理、二维码识别还得自己接。我早期做的项目就是这条路。一个capCreateCaptureWindowA建预览窗口一个capDriverConnect连摄像头capGrabFrameNoStop抓帧capFileSaveDIB存成BMP核心就这么几个API。好处是代码完全可控出问题能从头查到尾不黑盒。后面会详细展开实现过程这套API组合到今天依然能用尤其是那些没有厂商SDK的普通USB摄像头。2.3 本地中间服务最灵活也最推荐如果识别需求复杂比如要识别二维码、要做人脸裁剪、要自动纠偏那纯靠PB就力不从心了。这时可以写一个很小的本地服务C#或C都行内部调用ZXing、OpenCV这些库负责摄像头采集和图像识别PB通过本地HTTP或命令行参数跟它通信。这个方案把PB不擅长的事拆给擅长的人做两边都舒服。我在新项目里基本都推荐这条路。处理一张图片时PB只负责传路径、收结果中间服务把二维码内容、条码内容、旋转角度、裁剪坐标一次性返回。这样即使以后要换识别引擎改中间服务就行PB端代码几乎不用动。2.4 三条路怎么选方案优点缺点适合场景厂商SDK/OCX开发量小功能全绑定设备调式困难设备型号固定、识别需求简单avicap32.dll通用性强代码可控无图像处理需自己扩展要兼容多型号USB摄像头本地中间服务功能上限高易扩展多一个进程部署稍重识别要求高、长期维护项目3. 证件照拍照实现从画面预览到图片落盘这一节直接讲avicap32.dll这套路的完整实现因为它是三条路里最底层、最能讲透原理的。就算你最后选了中间服务方案理解了这套API的工作方式排查问题时也有底气。3.1 初始化预览窗口先在PB窗口上放一个Picture控件叫p_preview用它当预览画面的容器。然后在窗口的Open事件里写初始化逻辑声明外部函数这一步不能省。FUNCTION ulong capCreateCaptureWindowA(string lpszWindowName, ulong dwStyle, int x, int y, int w, int h, ulong hParent, int nID) LIBRARY avicap32.dll FUNCTION boolean capDriverConnect(ulong hCapWnd, int iDriver) LIBRARY avicap32.dll FUNCTION boolean capDriverDisconnect(ulong hCapWnd) LIBRARY avicap32.dll FUNCTION boolean capPreviewRate(ulong hCapWnd, int wms) LIBRARY avicap32.dll FUNCTION boolean capPreview(ulong hCapWnd, boolean fPreview) LIBRARY avicap32.dll FUNCTION boolean capGrabFrameNoStop(ulong hCapWnd) LIBRARY avicap32.dll FUNCTION boolean capFileSaveDIB(ulong hCapWnd, string sFileName) LIBRARY avicap32.dll然后是初始化代码ulong ll_hcap // 创建视频捕获窗口挂到预览Picture控件上 ll_hcap capCreateCaptureWindowA(Capture, 0, 0, 0, 640, 480, Handle(p_preview), 0) if ll_hcap 0 then MessageBox(错误, 创建视频捕获窗口失败) return end if // 连接摄像头0表示第一个设备 if capDriverConnect(ll_hcap, 0) false then MessageBox(错误, 连接摄像头失败请检查USB连接) return end if capPreviewRate(ll_hcap, 30) capPreview(ll_hcap, true)这里有个关键点capDriverConnect的第二个参数是设备索引。0代表系统默认摄像头如果机器上同时插了高拍仪和普通USB摄像头实际连接哪个不一定后面第五部分会专门讲这个坑。另外capPreviewRate给到30帧每秒是上限实际窗口办事场景用20就够了能明显降低CPU占用。3.2 抓帧与保存预览稳定之后拍照动作就简单了。用户点采集按钮执行一次抓帧然后把当前帧存成BMP文件。string ls_bmp_file boolean lb_ok ls_bmp_file d:\capture\temp.bmp lb_ok capGrabFrameNoStop(ll_hcap) if lb_ok false then MessageBox(错误, 抓帧失败) return end if capFileSaveDIB(ll_hcap, ls_bmp_file)两个细节要注意。第一capGrabFrameNoStop和capGrabFrame的区别是前者抓完帧后预览画面不会冻结用户感觉不到画面卡顿窗口办事体验更顺。第二capFileSaveDIB只支持BMP格式一张1200万像素的BMP动辄几十MB所以下一步必须做转换。3.3 BMP转JPG与图片瘦身PB自带Picture对象可以完成BMP到JPG的转换不需要额外引入第三方DLL。Picture lp_pic lp_pic Create Picture lp_pic.PictureName ls_bmp_file lp_pic.SaveAs(ls_jpg_file, JPEG!) Destroy lp_pic // 转换完成后删除临时BMP FileDelete(ls_bmp_file)保存成JPG之后文件大小会大幅下降。但还有个问题高拍仪抓出来的原图尺寸很大证件照归档其实不需要那么高分辨率。我一般会把图缩到宽1200像素左右再存这样既保证证件的清晰度又不会让数据库或文件服务器存储压力太大。PB里可以用lp_pic.Resize或者中间服务处理如果要批量处理建议丢给本地服务统一做。3.4 拍照按钮的完整交互逻辑一个真正能用的采集按钮逻辑不能只是抓帧存文件。要考虑防重复点击、管理当前会话状态、记录拍摄时间。// 拍照按钮Clicked事件 if ib_shooting then MessageBox(提示, 正在处理中请稍候) return end if ib_shooting true // 抓帧前先等200毫秒让自动曝光稳定 Sleep(200) capGrabFrameNoStop(ll_hcap) capFileSaveDIB(ll_hcap, ls_bmp_path) // 转JPG、生成缩略图、回显到DataWindow ... ib_shooting false这里Sleep函数需要声明Windows APIPB本身没有原生Sleep。窗口关闭事件里必须调用capDriverDisconnect否则摄像头一直处于占用状态下次打开会连不上。4. 二维码识别PB程序的外挂识别方案PB本身没有任何现成的二维码识别库这是很多第一次做高拍仪需求的人最头疼的地方。标题里的二维码识别在实际窗口场景里通常是指识别证件上的二维码、单据上的条码把编号自动填到表单里。要解决这个问题得先理清自己手里有什么资源。4.1 三个方案怎么选第一个方案是用厂商SDK自带的识别。如果高拍仪厂商的SDK提供识别接口直接调用最省事但识别率取决于厂商算法而且换了设备就失效。第二个方案是调线上识别API政务内网环境经常不通外网直接排除。第三个方案是本地识别用一个命令行工具或本地HTTP服务把ZXing或OpenCV的能力包装起来PB负责传图片、收结果。这个方案识别率有保障且完全离线是我唯一会主动推荐的。4.2 命令行识别器最接地气的一条路老PB项目最怕引入复杂的新运行时所以命令行方式是最稳妥的落地方式。思路很简单写一个小exe比如QrReader.exe接收图片路径和结果文件路径两个参数识别完毕后把结果写进文本文件PB等文件生成后读取内容。QrReader.exe d:\capture\card.jpg d:\capture\result.txtPB端调用string ls_cmd, ls_result_file, ls_result integer li_file ls_result_file d:\capture\result.txt FileDelete(ls_result_file) ls_cmd QrReader.exe ls_image_path ls_result_file Run(ls_cmd, Normal!) // 循环等待识别结果文件生成 li_file FileOpen(ls_result_file, TextMode!, Read!, Shared!) do while li_file 0 Yield() Sleep(100) li_file FileOpen(ls_result_file, TextMode!, Read!, Shared!) loop FileRead(li_file, ls_result) FileClose(li_file)等文件那里要注意不要写死循环要加一个超时退出机制比如最多等10秒。因为万一识别器崩了文件永远不会生成PB界面就会卡死。我这个方案看起来土但在PB 9到PB 2019的所有版本里都能跑不需要额外安装任何运行时排错也直观。4.3 本地识别服务的接口设计如果系统里有多个业务窗口都要用识别功能命令行反复启动进程会有开销更推荐起一个常驻的本地HTTP服务。接口设计得简单一点PB端用HTTP工具POST图片拿回JSON。POST http://127.0.0.1:17890/qr/decode Content-Type: application/json { imagePath: d:\capture\card.jpg }返回{ code: 0, data: [ { text: 证件编号123456, type: QR_CODE } ] }PB端在PB12以后可以用内置HTTPClient对象老版本则用WinINet的HttpSendRequestA或者直接调用命令行。JSON解析可以用PB的JSONParserPB2017老版本就得用字符串函数截取所以实际项目里我给老PB用户还是优先推荐命令行方案省掉不少兼容性麻烦。4.4 拍照后自动识别联动的细节拍照完成到识别完成时序设计要小心。不要一抓帧就立刻识别摄像头自动曝光和聚焦需要一点时间而且高拍仪拍出来的画面里二维码不一定占满画面边缘还可能有一圈黑色背景。稳妥的做法是先保存原图中间服务里做一次预处理把图像转成灰度、加大对比度再丢给识别器。实测下来同样的二维码预处理前后识别率差别非常明显。5. 实测踩坑实录从黑屏到内存上涨的完整排查这一节把我在真实项目里踩过的坑按排查链路写出来。高拍仪的问题一大半暴露在画面出不来和跑久了出问题这两类而且排查思路是通用的。5.1 预览黑屏先锁定三层黑屏最常见的三层原因驱动没装好、设备被占用、窗口句柄传错。拿到现场不要先怀疑代码按顺序查。第一步打开设备管理器看摄像头有没有被识别出来有不有黄色感叹号用系统自带的Camera应用直接打开摄像头如果系统相机也黑屏那就是驱动或硬件问题跟PB代码无关。第二步确认摄像头没被其他进程占用比如远程会议软件、另一个测试程序。第三步再回头看代码一般问题出在capCreateCaptureWindowA的父窗口句柄上。Handle(p_preview)必须在p_preview创建完成之后取如果窗口还没显示就执行句柄可能是0或无效捕获窗口创建在一个看不见的地方。还有一个隐蔽问题capPreview(ll_hcap, true)调用之后预览窗口会盖在Picture控件上面如果Picture控件的BringToTop属性设置不当预览画面会被其他控件遮挡看起来就像黑屏。5.2 内存上涨与预览卡顿avicap32这套API跑一整天后内存缓慢上涨是高频问题。根子通常在三个地方抓帧后创建的Picture对象没有销毁、预览帧率设置过高、频繁使用capGrabFrame而不是capGrabFrameNoStop。capGrabFrame内部会锁定画面如果调用频率高前一次的画面还没释放后一次又来了内存和句柄就开始累积。正确的做法是坚持用capGrabFrameNoStop只在真正需要保存时才抓帧。Picture对象用完必须DestroyPB的垃圾回收又不像C#那么及时靠系统回收等于内存泄漏。如果内存还涨用任务管理器看进程的GDI对象数。如果GDI对象数持续增加多半是某个地方创建了图形资源没释放。比如capFileSaveDIB保存BMP时如果该文件被其他进程锁定异常分支里跳过了后续清理也会导致问题。这种问题只能在代码上加异常保护确保退出前所有资源都被释放。5.3 摄像头设备号漂移capDriverConnect(ll_hcap, 0)里的0在不同机器上不一定代表同一个摄像头。USB接口插拔、驱动版本变化、系统更新都可能改变摄像头在视频捕获设备列表里的排列顺序。这在窗口现场非常常见调试机器上连的是高拍仪部署到用户机器上0号设备变成了另一个USB摄像头拍出来全是黑屏或者错误画面。解决办法是枚举设备列表让用户选择或者按名称自动匹配。用capGetDriverDescriptionA遍历设备索引把名称显示在窗口上的下拉框里默认选中含有USB Camera或设备厂商关键字的那一项。FUNCTION boolean capGetDriverDescriptionA(ulong wDriverIndex, ref string lpszName, uint cbName, ref string lpszVer, uint cbVer) LIBRARY avicap32.dll遍历时注意lpszName要先分配足量空间用Space(256)初始化否则API写入时会越界。实际项目中同一台机器上插着两个摄像头时这个枚举功能就是救命稻草。5.4 数据窗口回显图片与行高自适应拍完照把照片回显到PB数据窗口里是很多人忽略的一步。一放到DataWindow里就发现图片显示不完整或者行高不会自动撑开。这对应了pb数据窗口自动高度怎么设置这个高频搜索词。处理办法明确明细带Detail Band要勾选Auto Height图片列要把Autosize Height设为True。如果同一行里既有图片又有备注文字行高会以内容更高的一方为准所以要让图片列和文本列的Autosize都打开并且确保该行里没有固定高度的复合字段。另外要注意数据窗口里图片显示的刷新时机。拍摄完成后给数据窗口赋值如果列的值变了但画面没刷新可能是在事务里对同一行做了多次操作Update()之后要SetRedraw(true)。这个坑看起来小但在现场很耽误时间。5.5 光照、曝光与画面质量高拍仪一体机自带补光灯普通USB摄像头没有。窗口办公环境光线复杂上午和下午同一个位置的光线能差几个等级。曝光不足时证件上的二维码会识别失败因为二维码边缘的黑白反差被压平了。实测下来最省事的方案是在抓帧前加一个小延时等摄像头自动曝光稳定。一般从打开预览到画面亮度稳定需要500毫秒左右这个时间人眼可能感觉不到但程序立刻抓帧画面往往偏暗。如果还不行就在中间服务里做预处理图像转灰度、直方图均衡化能明显提升二维码识别率。对于证件照白平衡最好也在服务端做避免拍摄出来的身份证颜色发黄偏绿。6. 代码封装与工程化部署把摄像头逻辑散写在窗口事件里短期跑起来没问题长期维护一定噩梦。我的习惯是封装成一个用户对象nvo_camera对外只暴露fn_open()、fn_capture()、fn_close()、gn_last_error这几个接口。窗口里只需要调用方法不用碰API。// nvo_camera内部维护 ulong ih_capwnd窗口事件里写入几百行API代码换一台机器出问题后你根本不知道从哪查起。封装之后问题定位就集中了而且可以在fn_open()里自动做设备枚举和选择窗口层不用关心设备索引。部署阶段有几个容易被忽略的工程细节。PB应用打包时要带上对应版本的运行时DLL比如pbvm120.dll、pbdwe120.dll少了任何一个客户端都起不来。如果用了本地中间服务方案服务程序要注册成开机自启否则用户重启机器后识别功能就失效了。高拍仪一体机的驱动和厂商SDK要提前打包成一个静默安装脚本不能指望着窗口用户在部署现场手动点下一步。最后提醒一句如果你的生产环境里摄像头型号五花八门一定在上线前把所有型号接上去跑一遍把枚举到的设备名称存进日志文件。这个日志在远程排查为什么这台机器连不上摄像头时比任何代码分析都管用。我已经不止一次靠它省下了跑现场的油费。本文还有配套的精品资源点击获取
简介使用PowerBuilder开发的高拍仪与摄像头应用源码直接面向需要快速搭建证件照拍摄、二维码识别等桌面功能的软件开发者和系统集成商。源码实现摄像头实时图像采集、证件照尺寸与背景处理、OCR文字读取、二维码解码等核心能力并兼容PB 9、11.5和12.5多版本方便在不同开发环境中复用。压缩包共190个文件大小约89.71MB主要包含pbl、pbd工程源码dll运行库xml配置jpg、png图片素材exe演示程序以及修改日志等目录结构清晰便于按需提取。目前已有175人学习下载借助这套源码可以直观理解PowerBuilder如何通过API与摄像头交互、集成OpenCV等视觉库掌握数据窗口与底层设备协同开发的典型实现思路大幅节省同类项目的调研与联调时间附带的多版本工程与修改日志还能帮助开发者对比差异、追溯迭代过程适合作为图像采集与识别模块的改造蓝本。 很多年前我第一次听到用PB写高拍仪这个需求时第一反应是这玩意儿不是应该用C#或者Delphi写吗后来真进了现场才发现政务窗口那一排排老客户端十个里有七个是PowerBuilder写的高拍仪、身份证阅读器、二维码扫码枪全都得往这个老骨架里塞。今天想聊的pB源码高拍仪本质就是这么一件事在PB程序里把摄像头调起来拍证件照、扫描单证、识别二维码然后把采集到的数据接进现有业务流程。这个需求在窗口办事、柜台受理、档案电子化这类场景里太常见了。工作人员点一下拍照摄像头实时预览再点一下采集身份证或驾驶证就落到系统里如果证件上有二维码最好还能自动识别出来把号码填进表单。整个过程看起来没什么技术含量但真正把预览、抓帧、图片转换、二维码识别、数据窗口回显串起来并且做到连续跑一整天不崩坑其实不少。这篇文章就从选型开始把一条能落地的完整链路拆开讲清楚。1. 为什么到现在还有人用PB写高拍仪先说点实际的。很多业务系统是十几年前用PowerBuilder 9或者PB11写的数据库连的是Sybase或Oracle前端逻辑、审批流、打印模板全在里面重新用别的语言改写一轮成本高到没人愿意立项。这种情况下高拍仪这种新外设就只能嵌进老PB客户端里。所以不是PB适合干这个而是业务系统已经在这里外设必须迁就系统。一个典型的高拍仪客户端要完成的事情比想象中多。首先是视频预览让操作员看到镜头当前的画面然后是单帧抓取把画面定格成图片接着是图片处理裁剪、压缩、转成JPG归档再往后是内容识别比如二维码里存的证件号码、单据编号。如果是带副镜头的高拍仪一体机还要处理主摄像头拍文档、副摄像头拍人像的切换逻辑。这些功能单拎出来Windows自带的能力和第三方库都能做难点在于PB这个壳。它的生态早就停滞了很多新库没有官方绑定调用摄像头只能走API或外部进程图像处理也得绕路。但也正因为这样一旦你趟出了一条稳定路径这套代码能安安静静跑很多年。我这套方案在多个窗口项目上验证过核心逻辑基本没改过换的无非是摄像头型号和安装环境。2. 技术路线PB调用摄像头的三条路先说结论PB调摄像头没有银弹只有三条相对成熟的路选哪条取决于你手里的设备是什么、识别需求有多重。2.1 厂商SDK/OCX省事但绑定设备良田、华通、紫光这些高拍仪厂商大多会提供自己的SDK里面有预览、拍照、连拍、条码识别这类封装好的接口有些还带ActiveX控件可以直接拖进PB窗口里用。走这条路最省事尤其是厂商把副摄像头、补光灯、自动对焦都封装好之后程序代码量会小很多。但缺点是绑定太死。换了厂商或换型号SDK接口可能变代码要重新适配。更痛苦的是有些厂商只提供C#或Delphi的示例PB的例子压根没有你得自己用OLEObject去调用控件接口遇到文档缺失的地方全靠猜。还有一点老型号高拍仪的SDK识别能力普遍一般二维码识别率不如专用库如果对识别准确率要求高纯靠厂商SDK不一定够用。2.2 avicap32.dll底层原生自己动手这是Windows从老多媒体时代留下来的视频捕获接口PB通过声明外部函数可以直接调用不依赖任何厂商驱动。优点是通用性极强几乎所有USB摄像头都能认代码量也控制得住缺点是只解决取流和抓帧图像处理、二维码识别还得自己接。我早期做的项目就是这条路。一个capCreateCaptureWindowA建预览窗口一个capDriverConnect连摄像头capGrabFrameNoStop抓帧capFileSaveDIB存成BMP核心就这么几个API。好处是代码完全可控出问题能从头查到尾不黑盒。后面会详细展开实现过程这套API组合到今天依然能用尤其是那些没有厂商SDK的普通USB摄像头。2.3 本地中间服务最灵活也最推荐如果识别需求复杂比如要识别二维码、要做人脸裁剪、要自动纠偏那纯靠PB就力不从心了。这时可以写一个很小的本地服务C#或C都行内部调用ZXing、OpenCV这些库负责摄像头采集和图像识别PB通过本地HTTP或命令行参数跟它通信。这个方案把PB不擅长的事拆给擅长的人做两边都舒服。我在新项目里基本都推荐这条路。处理一张图片时PB只负责传路径、收结果中间服务把二维码内容、条码内容、旋转角度、裁剪坐标一次性返回。这样即使以后要换识别引擎改中间服务就行PB端代码几乎不用动。2.4 三条路怎么选方案优点缺点适合场景厂商SDK/OCX开发量小功能全绑定设备调式困难设备型号固定、识别需求简单avicap32.dll通用性强代码可控无图像处理需自己扩展要兼容多型号USB摄像头本地中间服务功能上限高易扩展多一个进程部署稍重识别要求高、长期维护项目3. 证件照拍照实现从画面预览到图片落盘这一节直接讲avicap32.dll这套路的完整实现因为它是三条路里最底层、最能讲透原理的。就算你最后选了中间服务方案理解了这套API的工作方式排查问题时也有底气。3.1 初始化预览窗口先在PB窗口上放一个Picture控件叫p_preview用它当预览画面的容器。然后在窗口的Open事件里写初始化逻辑声明外部函数这一步不能省。FUNCTION ulong capCreateCaptureWindowA(string lpszWindowName, ulong dwStyle, int x, int y, int w, int h, ulong hParent, int nID) LIBRARY avicap32.dll FUNCTION boolean capDriverConnect(ulong hCapWnd, int iDriver) LIBRARY avicap32.dll FUNCTION boolean capDriverDisconnect(ulong hCapWnd) LIBRARY avicap32.dll FUNCTION boolean capPreviewRate(ulong hCapWnd, int wms) LIBRARY avicap32.dll FUNCTION boolean capPreview(ulong hCapWnd, boolean fPreview) LIBRARY avicap32.dll FUNCTION boolean capGrabFrameNoStop(ulong hCapWnd) LIBRARY avicap32.dll FUNCTION boolean capFileSaveDIB(ulong hCapWnd, string sFileName) LIBRARY avicap32.dll然后是初始化代码ulong ll_hcap // 创建视频捕获窗口挂到预览Picture控件上 ll_hcap capCreateCaptureWindowA(Capture, 0, 0, 0, 640, 480, Handle(p_preview), 0) if ll_hcap 0 then MessageBox(错误, 创建视频捕获窗口失败) return end if // 连接摄像头0表示第一个设备 if capDriverConnect(ll_hcap, 0) false then MessageBox(错误, 连接摄像头失败请检查USB连接) return end if capPreviewRate(ll_hcap, 30) capPreview(ll_hcap, true)这里有个关键点capDriverConnect的第二个参数是设备索引。0代表系统默认摄像头如果机器上同时插了高拍仪和普通USB摄像头实际连接哪个不一定后面第五部分会专门讲这个坑。另外capPreviewRate给到30帧每秒是上限实际窗口办事场景用20就够了能明显降低CPU占用。3.2 抓帧与保存预览稳定之后拍照动作就简单了。用户点采集按钮执行一次抓帧然后把当前帧存成BMP文件。string ls_bmp_file boolean lb_ok ls_bmp_file d:\capture\temp.bmp lb_ok capGrabFrameNoStop(ll_hcap) if lb_ok false then MessageBox(错误, 抓帧失败) return end if capFileSaveDIB(ll_hcap, ls_bmp_file)两个细节要注意。第一capGrabFrameNoStop和capGrabFrame的区别是前者抓完帧后预览画面不会冻结用户感觉不到画面卡顿窗口办事体验更顺。第二capFileSaveDIB只支持BMP格式一张1200万像素的BMP动辄几十MB所以下一步必须做转换。3.3 BMP转JPG与图片瘦身PB自带Picture对象可以完成BMP到JPG的转换不需要额外引入第三方DLL。Picture lp_pic lp_pic Create Picture lp_pic.PictureName ls_bmp_file lp_pic.SaveAs(ls_jpg_file, JPEG!) Destroy lp_pic // 转换完成后删除临时BMP FileDelete(ls_bmp_file)保存成JPG之后文件大小会大幅下降。但还有个问题高拍仪抓出来的原图尺寸很大证件照归档其实不需要那么高分辨率。我一般会把图缩到宽1200像素左右再存这样既保证证件的清晰度又不会让数据库或文件服务器存储压力太大。PB里可以用lp_pic.Resize或者中间服务处理如果要批量处理建议丢给本地服务统一做。3.4 拍照按钮的完整交互逻辑一个真正能用的采集按钮逻辑不能只是抓帧存文件。要考虑防重复点击、管理当前会话状态、记录拍摄时间。// 拍照按钮Clicked事件 if ib_shooting then MessageBox(提示, 正在处理中请稍候) return end if ib_shooting true // 抓帧前先等200毫秒让自动曝光稳定 Sleep(200) capGrabFrameNoStop(ll_hcap) capFileSaveDIB(ll_hcap, ls_bmp_path) // 转JPG、生成缩略图、回显到DataWindow ... ib_shooting false这里Sleep函数需要声明Windows APIPB本身没有原生Sleep。窗口关闭事件里必须调用capDriverDisconnect否则摄像头一直处于占用状态下次打开会连不上。4. 二维码识别PB程序的外挂识别方案PB本身没有任何现成的二维码识别库这是很多第一次做高拍仪需求的人最头疼的地方。标题里的二维码识别在实际窗口场景里通常是指识别证件上的二维码、单据上的条码把编号自动填到表单里。要解决这个问题得先理清自己手里有什么资源。4.1 三个方案怎么选第一个方案是用厂商SDK自带的识别。如果高拍仪厂商的SDK提供识别接口直接调用最省事但识别率取决于厂商算法而且换了设备就失效。第二个方案是调线上识别API政务内网环境经常不通外网直接排除。第三个方案是本地识别用一个命令行工具或本地HTTP服务把ZXing或OpenCV的能力包装起来PB负责传图片、收结果。这个方案识别率有保障且完全离线是我唯一会主动推荐的。4.2 命令行识别器最接地气的一条路老PB项目最怕引入复杂的新运行时所以命令行方式是最稳妥的落地方式。思路很简单写一个小exe比如QrReader.exe接收图片路径和结果文件路径两个参数识别完毕后把结果写进文本文件PB等文件生成后读取内容。QrReader.exe d:\capture\card.jpg d:\capture\result.txtPB端调用string ls_cmd, ls_result_file, ls_result integer li_file ls_result_file d:\capture\result.txt FileDelete(ls_result_file) ls_cmd QrReader.exe ls_image_path ls_result_file Run(ls_cmd, Normal!) // 循环等待识别结果文件生成 li_file FileOpen(ls_result_file, TextMode!, Read!, Shared!) do while li_file 0 Yield() Sleep(100) li_file FileOpen(ls_result_file, TextMode!, Read!, Shared!) loop FileRead(li_file, ls_result) FileClose(li_file)等文件那里要注意不要写死循环要加一个超时退出机制比如最多等10秒。因为万一识别器崩了文件永远不会生成PB界面就会卡死。我这个方案看起来土但在PB 9到PB 2019的所有版本里都能跑不需要额外安装任何运行时排错也直观。4.3 本地识别服务的接口设计如果系统里有多个业务窗口都要用识别功能命令行反复启动进程会有开销更推荐起一个常驻的本地HTTP服务。接口设计得简单一点PB端用HTTP工具POST图片拿回JSON。POST http://127.0.0.1:17890/qr/decode Content-Type: application/json { imagePath: d:\capture\card.jpg }返回{ code: 0, data: [ { text: 证件编号123456, type: QR_CODE } ] }PB端在PB12以后可以用内置HTTPClient对象老版本则用WinINet的HttpSendRequestA或者直接调用命令行。JSON解析可以用PB的JSONParserPB2017老版本就得用字符串函数截取所以实际项目里我给老PB用户还是优先推荐命令行方案省掉不少兼容性麻烦。4.4 拍照后自动识别联动的细节拍照完成到识别完成时序设计要小心。不要一抓帧就立刻识别摄像头自动曝光和聚焦需要一点时间而且高拍仪拍出来的画面里二维码不一定占满画面边缘还可能有一圈黑色背景。稳妥的做法是先保存原图中间服务里做一次预处理把图像转成灰度、加大对比度再丢给识别器。实测下来同样的二维码预处理前后识别率差别非常明显。5. 实测踩坑实录从黑屏到内存上涨的完整排查这一节把我在真实项目里踩过的坑按排查链路写出来。高拍仪的问题一大半暴露在画面出不来和跑久了出问题这两类而且排查思路是通用的。5.1 预览黑屏先锁定三层黑屏最常见的三层原因驱动没装好、设备被占用、窗口句柄传错。拿到现场不要先怀疑代码按顺序查。第一步打开设备管理器看摄像头有没有被识别出来有不有黄色感叹号用系统自带的Camera应用直接打开摄像头如果系统相机也黑屏那就是驱动或硬件问题跟PB代码无关。第二步确认摄像头没被其他进程占用比如远程会议软件、另一个测试程序。第三步再回头看代码一般问题出在capCreateCaptureWindowA的父窗口句柄上。Handle(p_preview)必须在p_preview创建完成之后取如果窗口还没显示就执行句柄可能是0或无效捕获窗口创建在一个看不见的地方。还有一个隐蔽问题capPreview(ll_hcap, true)调用之后预览窗口会盖在Picture控件上面如果Picture控件的BringToTop属性设置不当预览画面会被其他控件遮挡看起来就像黑屏。5.2 内存上涨与预览卡顿avicap32这套API跑一整天后内存缓慢上涨是高频问题。根子通常在三个地方抓帧后创建的Picture对象没有销毁、预览帧率设置过高、频繁使用capGrabFrame而不是capGrabFrameNoStop。capGrabFrame内部会锁定画面如果调用频率高前一次的画面还没释放后一次又来了内存和句柄就开始累积。正确的做法是坚持用capGrabFrameNoStop只在真正需要保存时才抓帧。Picture对象用完必须DestroyPB的垃圾回收又不像C#那么及时靠系统回收等于内存泄漏。如果内存还涨用任务管理器看进程的GDI对象数。如果GDI对象数持续增加多半是某个地方创建了图形资源没释放。比如capFileSaveDIB保存BMP时如果该文件被其他进程锁定异常分支里跳过了后续清理也会导致问题。这种问题只能在代码上加异常保护确保退出前所有资源都被释放。5.3 摄像头设备号漂移capDriverConnect(ll_hcap, 0)里的0在不同机器上不一定代表同一个摄像头。USB接口插拔、驱动版本变化、系统更新都可能改变摄像头在视频捕获设备列表里的排列顺序。这在窗口现场非常常见调试机器上连的是高拍仪部署到用户机器上0号设备变成了另一个USB摄像头拍出来全是黑屏或者错误画面。解决办法是枚举设备列表让用户选择或者按名称自动匹配。用capGetDriverDescriptionA遍历设备索引把名称显示在窗口上的下拉框里默认选中含有USB Camera或设备厂商关键字的那一项。FUNCTION boolean capGetDriverDescriptionA(ulong wDriverIndex, ref string lpszName, uint cbName, ref string lpszVer, uint cbVer) LIBRARY avicap32.dll遍历时注意lpszName要先分配足量空间用Space(256)初始化否则API写入时会越界。实际项目中同一台机器上插着两个摄像头时这个枚举功能就是救命稻草。5.4 数据窗口回显图片与行高自适应拍完照把照片回显到PB数据窗口里是很多人忽略的一步。一放到DataWindow里就发现图片显示不完整或者行高不会自动撑开。这对应了pb数据窗口自动高度怎么设置这个高频搜索词。处理办法明确明细带Detail Band要勾选Auto Height图片列要把Autosize Height设为True。如果同一行里既有图片又有备注文字行高会以内容更高的一方为准所以要让图片列和文本列的Autosize都打开并且确保该行里没有固定高度的复合字段。另外要注意数据窗口里图片显示的刷新时机。拍摄完成后给数据窗口赋值如果列的值变了但画面没刷新可能是在事务里对同一行做了多次操作Update()之后要SetRedraw(true)。这个坑看起来小但在现场很耽误时间。5.5 光照、曝光与画面质量高拍仪一体机自带补光灯普通USB摄像头没有。窗口办公环境光线复杂上午和下午同一个位置的光线能差几个等级。曝光不足时证件上的二维码会识别失败因为二维码边缘的黑白反差被压平了。实测下来最省事的方案是在抓帧前加一个小延时等摄像头自动曝光稳定。一般从打开预览到画面亮度稳定需要500毫秒左右这个时间人眼可能感觉不到但程序立刻抓帧画面往往偏暗。如果还不行就在中间服务里做预处理图像转灰度、直方图均衡化能明显提升二维码识别率。对于证件照白平衡最好也在服务端做避免拍摄出来的身份证颜色发黄偏绿。6. 代码封装与工程化部署把摄像头逻辑散写在窗口事件里短期跑起来没问题长期维护一定噩梦。我的习惯是封装成一个用户对象nvo_camera对外只暴露fn_open()、fn_capture()、fn_close()、gn_last_error这几个接口。窗口里只需要调用方法不用碰API。// nvo_camera内部维护 ulong ih_capwnd窗口事件里写入几百行API代码换一台机器出问题后你根本不知道从哪查起。封装之后问题定位就集中了而且可以在fn_open()里自动做设备枚举和选择窗口层不用关心设备索引。部署阶段有几个容易被忽略的工程细节。PB应用打包时要带上对应版本的运行时DLL比如pbvm120.dll、pbdwe120.dll少了任何一个客户端都起不来。如果用了本地中间服务方案服务程序要注册成开机自启否则用户重启机器后识别功能就失效了。高拍仪一体机的驱动和厂商SDK要提前打包成一个静默安装脚本不能指望着窗口用户在部署现场手动点下一步。最后提醒一句如果你的生产环境里摄像头型号五花八门一定在上线前把所有型号接上去跑一遍把枚举到的设备名称存进日志文件。这个日志在远程排查为什么这台机器连不上摄像头时比任何代码分析都管用。我已经不止一次靠它省下了跑现场的油费。本文还有配套的精品资源点击获取
