简介在PowerBuilder应用中嵌入Web浏览器组件是开发混合型客户端的一种常见需求。这份资源以“pb使用web浏览器组件”为主题演示在PB9及Windows XP环境下通过WebBrowser/ActiveX控件实现应用内导航与Web交互的典型做法适用于维护旧版PB系统或需要内嵌网页功能的开发者。压缩包共88个文件大小约358KB核心包含.pbl库文件、.pbt工程文件以及html/htm页面、js/css脚本样式、jpg/gif图片和应用图标等配套素材结构清晰适合作为PB内嵌网页导航功能的参考样例。该资源已有1368人学习/浏览。从文件组织可以看出资源展示了PowerBuilder库中对象的设计方式、本地HTML及前端资源如何被Web浏览器组件加载同时也涉及.pbl/.pbt文件协作与版本管理的基本用法对理解PB控件集成、项目文件结构及老平台兼容性均有帮助可直接借鉴其中的实现思路用于自身项目。 PowerBuilderPB这个东西很多年轻开发者可能都没听过但在企业级应用尤其是HIS医院信息系统、MIS、ERP这类传统行业软件里它至今还在关键岗位上扛着。我过去几年维护和重构PB项目时碰到的需求里最头疼也最常被问到的就是“怎么在PB界面里嵌入网页”。这需求听起来简单不就是个浏览器控件吗但真做起来细节和坑都不少。这篇就把我在实际项目里用PB的Web Browser ActiveX组件做内嵌网页、做和页面交互的经验完整梳理一遍从控件选型、环境准备到双向通信、打印处理再到各种疑难杂症的排查一次说透。1. 为什么要在PB里嵌入浏览器组件1.1 场景判断什么项目真正需要Web浏览器组件先说结论不是所有系统都需要在PB里嵌网页。我见过不少项目纯粹因为领导一句话“把那个网页放进去”就把自己坑进去了。真正合理的场景我总结下来有三类第一类是旧系统补新功能。公司已经有了成熟的Web端系统比如基于Vue、React的单页应用不想在PB里再重写一遍最省事的办法就是直接嵌一个浏览器组件把现有页面显示出来。这种情况在HIS行业特别常见老的核心业务在PB里新的报表、大屏展示、移动端管理后台用的是Web技术两者需要共存。第二类是数据展示型页面。比如ECharts图表、地图可视化、流媒体播放器用PB原生控件做极其痛苦但Web端生态成熟几天就能搞定。这类页面通常只读、交互少非常适合内嵌。第三类是业务需要外部页面支撑。比如电子签章、网银支付跳转、扫码登录这些功能依赖第三方网页本来就是Web形态你不可能在PB里从零实现一个SDK去对接。反过来说如果业务是以表单录入、数据增删改查为主Web页面只是简单包了一层那还不如直接用PB的数据窗口。强行嵌网页性能、维护、交互都会成倍变差。选型前先想清楚这一层。1.2 架构层面的选型思路原生OLE控件、第三方控件还是独立进程确定了要用浏览器组件之后紧接着要选实现方式。PB本身不自带浏览器窗口但它作为Windows下的老牌开发工具对OLE和ActiveX的支持一直很扎实。综合我的实战经验方案基本就三条路第一条路是直接用系统自带的Web Browser ActiveX控件ProgID为Shell.Explorer或Shell.Explorer.2。这是IE内核MSHTMLWindows系统自带不需要额外安装任何东西注册表里默认就有。优点是不用部署、兼容性好、和PB的OLE接口对接最顺滑缺点是内核老旧对现代前端框架Vue3、React新版本支持吃力CSS3动画、ES6语法很可能渲染不正常。第二条路是第三方WebView控件比如WebView2Chromium内核。这个方案性能好、兼容现代Web标准但需要额外部署运行时Evergreen Runtime大概一百多MB而且PB调用它属于OLE包一层事件处理、窗口焦点管理都会麻烦一些。第三条路是独立进程隔离也就是把网页部分做成一个独立的程序比如C#写的WinForm宿主PB通过进程通信去调。这个方案架构最干净但开发量最大适合团队里有多语言开发能力的场景。我在大多数项目里选的是第一条路也就是Shell.Explorer这个ActiveX控件。原因很直接医院、银行、政企这些环境客户机器Windows版本参差不齐网络策略严格你不可能为了一个内嵌页面去给每台终端装运行时。系统自带控件虽然丑了点、老了点但它稳定、永远可用对于展示型页面和内部管理系统够用了。2. 接入前的准备工作与界面设计2.1 开发环境与控件注册检查PB开发环境下往窗口上放Web Browser控件非常简单在窗口画板里选择ActiveX控件弹出的列表里找到“Microsoft Web Browser”或者“WebBrowser”ProgID是Shell.Explorer选中后拖到窗口上就行了。这里有一个非常关键的检查点目标机器上这个控件到底存不存在。几乎所有家用和办公Windows系统都自带IE组件但少数精简版系统、Windows Server Core版本或定制的政企镜像可能会把这个组件裁掉。所以第一件事就是在代码里加一个注册表检查判断HKEY_CLASSES_ROOT\Shell.Explorer\CLSID是否存在不存在就给用户一个明确的提示而不是让程序运行时抛一个让人摸不着头脑的OLE错误。我在实际项目中是写了个函数在窗口Open事件里调用代码大概是这样的// 窗口Open事件里检查控件是否可用 integer li_handle string ls_clsid registryget(HKEY_CLASSES_ROOT\Shell.Explorer\CLSID, , ls_clsid, regstring!) if len(ls_clsid) 0 then messagebox(环境检查, 当前系统缺少IE浏览器组件无法显示内嵌网页请联系管理员处理...) // 可以在这里决定是否关闭窗口或降级为提示 end if这事看起来小但特别影响用户体验。否则你在开发机上跑得好好的到了客户那边一打开窗口就崩溃或者空白排查半天才意识到是控件缺失就晚了。2.2 主从双界面架构设计PB壳加Web内容嵌入浏览器组件之后整个窗口在架构上就变成了“PB壳 Web内容”的主从结构。这句话是什么意思就是要把职责划分清楚PB窗口负责程序的骨架比如标题栏、菜单、按钮、状态栏、侧边导航浏览器组件负责业务内容的渲染比如表格、统计图表、操作面板。两者各管一摊尽量不要有重叠。为什么强调这个因为很多人一开始就把整个窗口塞满浏览器控件结果发现PB菜单用不了了本地数据窗口弹不出来窗口底部的状态栏也被网页挡住。我推荐的设计是把浏览器控件放在一个GroupBox或者Tab页的某个区域里固定大小和位置周围保留PB原生的导航和操作区域。好处有三个一是用户感知上还是“PB系统”而不是“套了个浏览器的网页”二是PB侧的业务操作比如点击侧边栏触发查询、数据窗口联动可以随时和页面交互互相不干扰三是窗口尺寸变化时只需要控制浏览器控件的宽度高度不会影响全局布局。实际操作时我会把浏览器控件的Resize事件也写一下让它在窗口改变大小时自动跟随调整。PB的窗口没有布局管理器全靠代码算位置这个简单但必须写的逻辑很多人会漏掉。2.3 初始化事件里该做的几件事窗口初始化也就是Open事件里除了环境检查还需要做三件事第一设置浏览器控件的初始属性。比如设置Silent属性为True避免页面脚本报错时弹出IE的脚本错误对话框。这个不设置的话页面上一个简单的JS异常就会把错误框怼到用户脸上极其影响体验。// 初始化WebBrowser属性 ole_web.object.Silent : true第二设置浏览器控件的尺寸和位置。根据窗口工作区大小算好让控件占满目标区域同时不要覆盖其他PB按钮。第三加载初始页面。本公司内部系统的地址或者一个空白页都可以。注意加载页面用Navigate方法这个方法有四个参数第二个参数是Flags通常传0即可第三个参数是目标帧名一般不填第四个是Post数据一般也不用。// 导航到初始页面 ole_web.object.Navigate(http://10.10.1.100:8080/reportcenter/index.html, 0, , , )这里强烈建议把URL放到配置表或INI文件里不要把IP和端口硬编码在代码里。因为系统交付之后客户换服务器、改端口太常见了。我在HIS项目里维护过一段深有体会没做配置化的项目客户每次改地址都要找开发改代码重新编译极其痛苦。3. 核心接口与JS-PB双向调用的实现3.1 常用方法Navigate、Refresh、GoBack与执行JavaScriptWeb Browser控件本质上是对IE的OLE封装它暴露的接口跟IE的IWebBrowser2接口基本一致。最常用的方法有这么几个Navigate(URL, Flags, TargetFrameName, PostData, Headers)加载指定URL。Refresh()刷新当前页面。GoBack()/GoForward()浏览器历史后退/前进。Stop()停止加载。ExecWB(OLECMDID, OLECMDEXECOPT, In, Out)执行浏览器命令比如复制、查找、打印。这个后面讲打印的时候细说。这里面最实用的技巧是用Navigate执行JavaScript代码。PB没有专门“调用页面JS函数”的接口但可以通过导航到javascript:xxx这种伪协议来触发页面里的函数。// 调用页面里的刷新数据函数 string ls_js ls_js javascript:refreshData( ls_param ); ole_web.object.Navigate(ls_js, 0, , , )这里有一个要注意的坑页面里的JS函数名必须存在否则浏览器会打开一个包含错误信息的新页面或者在控制台里报错用户在PB界面上看到的效果就是页面突然没了变成了一堆英文字符。我在调试阶段遇到很多次。稳妥做法是页面和PB约定一个统一的“出入口函数”比如PBInvoke(action, param)PB这边所有调用都走这个函数页面内部再根据action分发给具体逻辑。这样比一个个函数名散着调要规范得多也方便页面侧做统一的参数校验和错误处理。3.2 从网页调PB业务模型OLE对象暴露与安全校验刚才讲的是PB往页面里塞数据这是单向的。实际业务里更复杂也更常见的需求是反过来的网页上的按钮点击之后要调用PB窗口里的函数、要查数据窗口、要弹出PB的弹窗。这就涉及到“从网页调PB模型”了也是热词里“调用pb模型”这件事的核心。实现原理不复杂。Web Browser控件有一个Document属性拿到的是当前页面的HTMLDocument对象。最关键的是页面里的JS可以通过window.external访问到宿主程序暴露的OLE对象。在PB里只要我们给浏览器控件设置好ObjectForScripting这个属性页面JS就可以调用这个对象上的方法了。但需要注意在PB的ActiveX封装里设置ObjectForScripting并不像C#的WebBrowser控件那么直观。常规做法是定义一个自定义类用户对象Custom Class里面写好你要暴露给网页的方法然后在窗口Open事件里把这个用户对象实例赋值给浏览器控件的ObjectForScripting属性。// 窗口Open事件中设置脚本注入对象 inv_script_obj create n_script_bridge ole_web.object.ObjectForScripting : inv_script_obj其中n_script_bridge这个自定义类里需要定义一个公共方法供JS调用比如// n_script_bridge 中的方法定义 public function string PBGetData(string as_action, string as_param) // 可以根据action调用不同窗口、数据窗口、业务服务 choose case as_action case get_patient_info return dw_patient.object.name[1] , dw_patient.object.age[1] case get_order_detail // ... end choose return end function页面JS那边调用方式类似于// 页面中调用PB暴露的方法 var result window.external.PBGetData(get_patient_info, 12345);这里我必须强调安全校验window.external是暴露给整个页面的能力如果页面上有第三方JS脚本比如统计脚本、广告脚本虽然内嵌系统里一般没有但万一有理论上它们也能调用PB的方法。所以暴露的方法里一定要做参数校验和权限判断至少要做到白名单action校验、敏感操作的session或token校验、关键数据脱敏。我在一个项目里吃过亏网页里的支付回调直接调了PB的“打单”函数结果被脚本循环调用打了一堆单子出来后来才加的校验。3.3 事件处理DocumentComplete与窗口关闭联动除了主动调用浏览器控件的事件处理同样重要。最常用的事件是DocumentComplete它在页面加载完成后触发。这个事件在PB里对应的写法是给OLE控件定义事件订阅。在窗口画板里选中Web Browser控件在Events页签里找到DocumentComplete事件双击进去就能写代码。我这里实战中经常用到的一个思路在DocumentComplete事件里做页面初始化比如往页面里注入用户信息、设置页面主题色、调整页面布局。// DocumentComplete事件里做初始化注入 string ls_init_js ls_init_js javascript:initApp( gs_user_code , gs_user_name ); ole_web.object.Navigate(ls_init_js, 0, , , )另一个很实用的事件是NavigateComplete2它在每次导航完成时触发包括点击页面里链接导致的新导航。如果你想让某些外部链接不在内嵌浏览器里打开而是调用系统默认浏览器可以在这个事件里做判断拦截。窗口关闭联动也特别重要。内嵌的浏览器控件往往会因为页面里的动画、长连接、循环定时器导致PB窗口关不掉或者关掉之后后台进程还在跑。如果窗口Close事件里只是简单地close(this)很多时候你会发现窗口关了但应用程序的进程还挂在任务管理器里。解决办法是在窗口Close事件里先释放浏览器控件资源导航到空白页再销毁OLE对象。// 窗口Close事件里释放WebBrowser资源 ole_web.object.Navigate(about:blank, 0, , , ) destroy inv_script_obj close(this)这个步骤看起来多余但实际非常管用。不释放资源的话用户开着系统一整天反复打开关闭内嵌页面窗口内存占用会越来越大最后界面卡顿到点不了按钮。4. 完整实操做一个内嵌报表加载器4.1 需求与界面设计为了把上面的知识点串起来我拿一个实际做过的需求当例子医院信息系统里要给医生工作站加一个“手术统计报表”页面数据展示用ECharts但入口和权限在PB的老系统里要求医生点击菜单后在PB窗口内打开页面并且把当前登录医生的科室传过去页面按科室过滤数据。界面设计很简单一个窗口w_report_browser顶部是一个静态文本显示当前报表名中间放Web Browser控件ole_web底部是两个按钮——“刷新数据”和“打印报表”。整体界面保持PB风格不需要花哨的UI客户要的是稳定。4.2 加载页面并回传参数窗口Open事件里读取配置文件URL拼接上查询参数然后导航到报表页面。// w_report_browser.Open事件 string ls_url, ls_dept_code, ls_user_code ls_url gnv_config.GetValue(ReportServer, base_url) ls_dept_code gnv_pub.dept_code ls_user_code gnv_pub.user_code // 拼接参数页面根据参数按科室过滤 ls_url /surgery_statistics.html?dept ls_dept_code user ls_user_code ole_web.object.Silent : true ole_web.object.Navigate(ls_url, 0, , , )这里有个细节参数传递尽量别用POST因为Navigate的PostData参数处理起来比较别扭而且URL参数方式在做页面调试时更方面——你直接在浏览器里打开带参URL就能看到和PB里一致的效果。如果参数里有中文或特殊字符记得先做URL编码PB里有UrlEncode函数或者用escape函数处理否则页面收到的参数会出现乱码。4.3 刷新与打印功能实现“刷新数据”按钮的逻辑不复杂就是调用页面里的刷新函数。但注意报表页面往往有自己的查询条件区域刷新应该保留用户当前的选择而不是把页面重新加载一遍。所以更合理的按钮交互是让页面自己负责刷新PB只触发事件。// cb_refresh.clicked事件 string ls_js ls_js javascript:doRefresh(); ole_web.object.Navigate(ls_js, 0, , , )“打印报表”要分两种处理。如果页面是纯前端绘制比如ECharts图表导出图片那PB侧调用ExecWB实现浏览器打印这种方式打印的是整个页面包含按钮、图表、标题但它的打印预览对话框是浏览器自带的样式可控性差。很多报表场景其实更希望走“调用页面里的打印函数页面自己控制打印模板”的路子。// cb_print.clicked事件 // 方式一浏览器原生打印 ole_web.object.ExecWB(6, 1, 0, 0) // OLECMDID_PRINT 6 // 或者方式二让页面里的JS处理 string ls_js ls_js javascript:doPrint(); ole_web.object.Navigate(ls_js, 0, , , )两种方式我都用过更推荐方式二。因为方式一的浏览器原声打印会打出整张页面包括顶上那个“手术统计报表”的标题和按钮位置往往会有空白页或者页眉页脚问题调起来很费劲。页面内部用CSS的media print来定制打印样式干净得多。4.4 数据窗口打印预览的补充说明热词里有一条“pb的数据窗口有printpreview()函数吗”很多人其实是在做报表时搞混了数据窗口和Web报表的分工。这里我顺着说清楚PB的数据窗口确实有打印预览能力但方法名是PrintPreview()不是printpreview()而且在调用前需要设置数据窗口的Print.Preview属性为True。// 数据窗口打印预览标准写法 dw_report.Object.DataWindow.Print.Preview : True dw_report.PrintPreview() // 退出预览模式 dw_report.Object.DataWindow.Print.Preview : False数据窗口适合打印那种规规矩矩的表格单据比如检验报告单、处方单Web报表适合带图表、视觉化展示的场景。在同一个系统里两者配合使用的思路是数据窗口处理格式固定的单据Web页面处理可视化分析报表各司其职。我不建议在一个场景里混用尤其不要试图在Web页面里打印数据窗口的内容那会变成一个无尽的坑。5. 常见问题与排查实录5.1 页面空白或加载不出来嵌入式浏览器的第一大坑就是页面空白。原因从常见的可能性依次排查第一URL不通。这个最多见。开发机访问正常但客户内网访问不了服务器的80端口或者8080端口。先让客户在终端机器上用IE手动打开地址试试能开再谈组件问题。第二脚本错误导致白屏。很多前端框架在IE内核下运行会抛错而错误被吞掉之后渲染就中断了。我前面说的Silent : true只是不弹错误框但不能解决真正JS出错的问题。排查时要临时把Silent改成False让错误框弹出看具体是什么错误。常见的是浏览器不支持某些ES6语法或CSS3特性。第三ActiveX控件本身没有成功实例化。窗口设计器里能拖进来不代表运行时一定成功特别是在开发者用64位PB编译、目标机器是32位系统或者反过来的时候。虽然Web Browser控件是系统级的但OLE实例化偶尔也会出幺蛾子。解决办法是在代码里加一个OLE实例化成功的判断。// 检查OLE对象是否可用 if isnull(ole_web.object) then messagebox(错误, 浏览器组件加载失败) end if第四兼容性视图设置。IE内核默认有兼容性视图如果你在开发时加了meta标签指定IE版本部署时也要确保目标机器的注册表或者组策略没有强制企业模式否则会走低版本渲染模式页面完全变形。5.2 页面里的弹窗被拦截或显示异常Web页面上常见的window.open弹窗在PB嵌入式浏览器里经常会被当成“弹出窗口”拦截虽然它没有独立的弹出窗口拦截器但很多页面逻辑里用window.showModalDialog或者window.open打开的对话框行为会变得难以预测。有些是根本打不开有些是打开了但没有模态效果用户可以乱点。这个问题的根治思路是不要在页面上使用依赖弹窗的交互改为页面内部用div遮罩来实现“伪弹窗”。因为嵌入式浏览器的弹窗本质上是走了系统的IE窗口它在PB窗口的Z轴顺序、焦点控制上都很难完美。我在项目里会明确要求前端团队内嵌页面禁止使用window.showModalDialog、禁止window.open有弹窗需求一律用自绘Modal组件。如果实在没法改前端可以尝试在NewWindow2事件里做处理把新窗口导航到当前控件但那个做法很麻烦还容易出现多个页面互相覆盖导航的问题我只能说能实现但不推荐。5.3 内存只增不减、窗口关闭卡死这是内嵌网页最容易被诟病的问题。表面现象是系统开几天后越来越卡内存占用持续上升。原因基本是页面里有定时器、动画、WebSocket连接没有正确销毁加上PB关闭窗口时没有释放OLE资源。这一块我在第3.3节提到过资源释放是关键。我再补充一个实战技巧如果页面里用了WebSocket或者SSE长连接PB关闭窗口前最好先通知页面主动断开连接不然即使PB这边释放了资源服务端那边可能还挂着失效的会话。我做一个项目时页面里用一个WebSocket接收检查报告推送用户直接关窗口不通知页面断开服务端会话堆积了几百个把服务器搞崩了。后来在窗口Close事件里先调用javascript:beforePageClosed();通知前端清理再Navigate(about:blank)、销毁对象这个问题就解决了。5.4 兼容性与性能调优心得最后说一点基于实际维护经验的心得吧。PB项目往往生命周期非常长一个HIS系统用个十年八年很正常。嵌入式浏览器组件这种方案虽然能用但每一次操作系统大版本升级、每一个前端框架版本迭代都可能带来新的兼容问题。我的应对策略是对外层做厚度隔离。什么意思就是在PB和具体页面之间加一个“适配层”不要让PB代码直接和页面里的具体JS函数名耦合。PB调页面统一走PBInvoke(action, param)这个入口页面回传数据统一走window.external.PBHandle(type, data)。这样上来讲后期页面改版、换前端框架、甚至换WebView组件PB侧的改动都能控制在很小范围内。我也遇到过项目把内嵌IE升级成WebView2的情况因为适配层设计得干净PB侧只换了控件初始化和几个基础调用业务代码基本没动。做企业级应用最怕的就是业务代码和技术细节拧成一团。把技术选择的代价限制在局部模块里把业务逻辑和通信协议稳定下来这个系统的寿命就会长很多。这也是我做了这么多年PB项目最想分享的一条经验。本文还有配套的精品资源点击获取
简介在PowerBuilder应用中嵌入Web浏览器组件是开发混合型客户端的一种常见需求。这份资源以“pb使用web浏览器组件”为主题演示在PB9及Windows XP环境下通过WebBrowser/ActiveX控件实现应用内导航与Web交互的典型做法适用于维护旧版PB系统或需要内嵌网页功能的开发者。压缩包共88个文件大小约358KB核心包含.pbl库文件、.pbt工程文件以及html/htm页面、js/css脚本样式、jpg/gif图片和应用图标等配套素材结构清晰适合作为PB内嵌网页导航功能的参考样例。该资源已有1368人学习/浏览。从文件组织可以看出资源展示了PowerBuilder库中对象的设计方式、本地HTML及前端资源如何被Web浏览器组件加载同时也涉及.pbl/.pbt文件协作与版本管理的基本用法对理解PB控件集成、项目文件结构及老平台兼容性均有帮助可直接借鉴其中的实现思路用于自身项目。 PowerBuilderPB这个东西很多年轻开发者可能都没听过但在企业级应用尤其是HIS医院信息系统、MIS、ERP这类传统行业软件里它至今还在关键岗位上扛着。我过去几年维护和重构PB项目时碰到的需求里最头疼也最常被问到的就是“怎么在PB界面里嵌入网页”。这需求听起来简单不就是个浏览器控件吗但真做起来细节和坑都不少。这篇就把我在实际项目里用PB的Web Browser ActiveX组件做内嵌网页、做和页面交互的经验完整梳理一遍从控件选型、环境准备到双向通信、打印处理再到各种疑难杂症的排查一次说透。1. 为什么要在PB里嵌入浏览器组件1.1 场景判断什么项目真正需要Web浏览器组件先说结论不是所有系统都需要在PB里嵌网页。我见过不少项目纯粹因为领导一句话“把那个网页放进去”就把自己坑进去了。真正合理的场景我总结下来有三类第一类是旧系统补新功能。公司已经有了成熟的Web端系统比如基于Vue、React的单页应用不想在PB里再重写一遍最省事的办法就是直接嵌一个浏览器组件把现有页面显示出来。这种情况在HIS行业特别常见老的核心业务在PB里新的报表、大屏展示、移动端管理后台用的是Web技术两者需要共存。第二类是数据展示型页面。比如ECharts图表、地图可视化、流媒体播放器用PB原生控件做极其痛苦但Web端生态成熟几天就能搞定。这类页面通常只读、交互少非常适合内嵌。第三类是业务需要外部页面支撑。比如电子签章、网银支付跳转、扫码登录这些功能依赖第三方网页本来就是Web形态你不可能在PB里从零实现一个SDK去对接。反过来说如果业务是以表单录入、数据增删改查为主Web页面只是简单包了一层那还不如直接用PB的数据窗口。强行嵌网页性能、维护、交互都会成倍变差。选型前先想清楚这一层。1.2 架构层面的选型思路原生OLE控件、第三方控件还是独立进程确定了要用浏览器组件之后紧接着要选实现方式。PB本身不自带浏览器窗口但它作为Windows下的老牌开发工具对OLE和ActiveX的支持一直很扎实。综合我的实战经验方案基本就三条路第一条路是直接用系统自带的Web Browser ActiveX控件ProgID为Shell.Explorer或Shell.Explorer.2。这是IE内核MSHTMLWindows系统自带不需要额外安装任何东西注册表里默认就有。优点是不用部署、兼容性好、和PB的OLE接口对接最顺滑缺点是内核老旧对现代前端框架Vue3、React新版本支持吃力CSS3动画、ES6语法很可能渲染不正常。第二条路是第三方WebView控件比如WebView2Chromium内核。这个方案性能好、兼容现代Web标准但需要额外部署运行时Evergreen Runtime大概一百多MB而且PB调用它属于OLE包一层事件处理、窗口焦点管理都会麻烦一些。第三条路是独立进程隔离也就是把网页部分做成一个独立的程序比如C#写的WinForm宿主PB通过进程通信去调。这个方案架构最干净但开发量最大适合团队里有多语言开发能力的场景。我在大多数项目里选的是第一条路也就是Shell.Explorer这个ActiveX控件。原因很直接医院、银行、政企这些环境客户机器Windows版本参差不齐网络策略严格你不可能为了一个内嵌页面去给每台终端装运行时。系统自带控件虽然丑了点、老了点但它稳定、永远可用对于展示型页面和内部管理系统够用了。2. 接入前的准备工作与界面设计2.1 开发环境与控件注册检查PB开发环境下往窗口上放Web Browser控件非常简单在窗口画板里选择ActiveX控件弹出的列表里找到“Microsoft Web Browser”或者“WebBrowser”ProgID是Shell.Explorer选中后拖到窗口上就行了。这里有一个非常关键的检查点目标机器上这个控件到底存不存在。几乎所有家用和办公Windows系统都自带IE组件但少数精简版系统、Windows Server Core版本或定制的政企镜像可能会把这个组件裁掉。所以第一件事就是在代码里加一个注册表检查判断HKEY_CLASSES_ROOT\Shell.Explorer\CLSID是否存在不存在就给用户一个明确的提示而不是让程序运行时抛一个让人摸不着头脑的OLE错误。我在实际项目中是写了个函数在窗口Open事件里调用代码大概是这样的// 窗口Open事件里检查控件是否可用 integer li_handle string ls_clsid registryget(HKEY_CLASSES_ROOT\Shell.Explorer\CLSID, , ls_clsid, regstring!) if len(ls_clsid) 0 then messagebox(环境检查, 当前系统缺少IE浏览器组件无法显示内嵌网页请联系管理员处理...) // 可以在这里决定是否关闭窗口或降级为提示 end if这事看起来小但特别影响用户体验。否则你在开发机上跑得好好的到了客户那边一打开窗口就崩溃或者空白排查半天才意识到是控件缺失就晚了。2.2 主从双界面架构设计PB壳加Web内容嵌入浏览器组件之后整个窗口在架构上就变成了“PB壳 Web内容”的主从结构。这句话是什么意思就是要把职责划分清楚PB窗口负责程序的骨架比如标题栏、菜单、按钮、状态栏、侧边导航浏览器组件负责业务内容的渲染比如表格、统计图表、操作面板。两者各管一摊尽量不要有重叠。为什么强调这个因为很多人一开始就把整个窗口塞满浏览器控件结果发现PB菜单用不了了本地数据窗口弹不出来窗口底部的状态栏也被网页挡住。我推荐的设计是把浏览器控件放在一个GroupBox或者Tab页的某个区域里固定大小和位置周围保留PB原生的导航和操作区域。好处有三个一是用户感知上还是“PB系统”而不是“套了个浏览器的网页”二是PB侧的业务操作比如点击侧边栏触发查询、数据窗口联动可以随时和页面交互互相不干扰三是窗口尺寸变化时只需要控制浏览器控件的宽度高度不会影响全局布局。实际操作时我会把浏览器控件的Resize事件也写一下让它在窗口改变大小时自动跟随调整。PB的窗口没有布局管理器全靠代码算位置这个简单但必须写的逻辑很多人会漏掉。2.3 初始化事件里该做的几件事窗口初始化也就是Open事件里除了环境检查还需要做三件事第一设置浏览器控件的初始属性。比如设置Silent属性为True避免页面脚本报错时弹出IE的脚本错误对话框。这个不设置的话页面上一个简单的JS异常就会把错误框怼到用户脸上极其影响体验。// 初始化WebBrowser属性 ole_web.object.Silent : true第二设置浏览器控件的尺寸和位置。根据窗口工作区大小算好让控件占满目标区域同时不要覆盖其他PB按钮。第三加载初始页面。本公司内部系统的地址或者一个空白页都可以。注意加载页面用Navigate方法这个方法有四个参数第二个参数是Flags通常传0即可第三个参数是目标帧名一般不填第四个是Post数据一般也不用。// 导航到初始页面 ole_web.object.Navigate(http://10.10.1.100:8080/reportcenter/index.html, 0, , , )这里强烈建议把URL放到配置表或INI文件里不要把IP和端口硬编码在代码里。因为系统交付之后客户换服务器、改端口太常见了。我在HIS项目里维护过一段深有体会没做配置化的项目客户每次改地址都要找开发改代码重新编译极其痛苦。3. 核心接口与JS-PB双向调用的实现3.1 常用方法Navigate、Refresh、GoBack与执行JavaScriptWeb Browser控件本质上是对IE的OLE封装它暴露的接口跟IE的IWebBrowser2接口基本一致。最常用的方法有这么几个Navigate(URL, Flags, TargetFrameName, PostData, Headers)加载指定URL。Refresh()刷新当前页面。GoBack()/GoForward()浏览器历史后退/前进。Stop()停止加载。ExecWB(OLECMDID, OLECMDEXECOPT, In, Out)执行浏览器命令比如复制、查找、打印。这个后面讲打印的时候细说。这里面最实用的技巧是用Navigate执行JavaScript代码。PB没有专门“调用页面JS函数”的接口但可以通过导航到javascript:xxx这种伪协议来触发页面里的函数。// 调用页面里的刷新数据函数 string ls_js ls_js javascript:refreshData( ls_param ); ole_web.object.Navigate(ls_js, 0, , , )这里有一个要注意的坑页面里的JS函数名必须存在否则浏览器会打开一个包含错误信息的新页面或者在控制台里报错用户在PB界面上看到的效果就是页面突然没了变成了一堆英文字符。我在调试阶段遇到很多次。稳妥做法是页面和PB约定一个统一的“出入口函数”比如PBInvoke(action, param)PB这边所有调用都走这个函数页面内部再根据action分发给具体逻辑。这样比一个个函数名散着调要规范得多也方便页面侧做统一的参数校验和错误处理。3.2 从网页调PB业务模型OLE对象暴露与安全校验刚才讲的是PB往页面里塞数据这是单向的。实际业务里更复杂也更常见的需求是反过来的网页上的按钮点击之后要调用PB窗口里的函数、要查数据窗口、要弹出PB的弹窗。这就涉及到“从网页调PB模型”了也是热词里“调用pb模型”这件事的核心。实现原理不复杂。Web Browser控件有一个Document属性拿到的是当前页面的HTMLDocument对象。最关键的是页面里的JS可以通过window.external访问到宿主程序暴露的OLE对象。在PB里只要我们给浏览器控件设置好ObjectForScripting这个属性页面JS就可以调用这个对象上的方法了。但需要注意在PB的ActiveX封装里设置ObjectForScripting并不像C#的WebBrowser控件那么直观。常规做法是定义一个自定义类用户对象Custom Class里面写好你要暴露给网页的方法然后在窗口Open事件里把这个用户对象实例赋值给浏览器控件的ObjectForScripting属性。// 窗口Open事件中设置脚本注入对象 inv_script_obj create n_script_bridge ole_web.object.ObjectForScripting : inv_script_obj其中n_script_bridge这个自定义类里需要定义一个公共方法供JS调用比如// n_script_bridge 中的方法定义 public function string PBGetData(string as_action, string as_param) // 可以根据action调用不同窗口、数据窗口、业务服务 choose case as_action case get_patient_info return dw_patient.object.name[1] , dw_patient.object.age[1] case get_order_detail // ... end choose return end function页面JS那边调用方式类似于// 页面中调用PB暴露的方法 var result window.external.PBGetData(get_patient_info, 12345);这里我必须强调安全校验window.external是暴露给整个页面的能力如果页面上有第三方JS脚本比如统计脚本、广告脚本虽然内嵌系统里一般没有但万一有理论上它们也能调用PB的方法。所以暴露的方法里一定要做参数校验和权限判断至少要做到白名单action校验、敏感操作的session或token校验、关键数据脱敏。我在一个项目里吃过亏网页里的支付回调直接调了PB的“打单”函数结果被脚本循环调用打了一堆单子出来后来才加的校验。3.3 事件处理DocumentComplete与窗口关闭联动除了主动调用浏览器控件的事件处理同样重要。最常用的事件是DocumentComplete它在页面加载完成后触发。这个事件在PB里对应的写法是给OLE控件定义事件订阅。在窗口画板里选中Web Browser控件在Events页签里找到DocumentComplete事件双击进去就能写代码。我这里实战中经常用到的一个思路在DocumentComplete事件里做页面初始化比如往页面里注入用户信息、设置页面主题色、调整页面布局。// DocumentComplete事件里做初始化注入 string ls_init_js ls_init_js javascript:initApp( gs_user_code , gs_user_name ); ole_web.object.Navigate(ls_init_js, 0, , , )另一个很实用的事件是NavigateComplete2它在每次导航完成时触发包括点击页面里链接导致的新导航。如果你想让某些外部链接不在内嵌浏览器里打开而是调用系统默认浏览器可以在这个事件里做判断拦截。窗口关闭联动也特别重要。内嵌的浏览器控件往往会因为页面里的动画、长连接、循环定时器导致PB窗口关不掉或者关掉之后后台进程还在跑。如果窗口Close事件里只是简单地close(this)很多时候你会发现窗口关了但应用程序的进程还挂在任务管理器里。解决办法是在窗口Close事件里先释放浏览器控件资源导航到空白页再销毁OLE对象。// 窗口Close事件里释放WebBrowser资源 ole_web.object.Navigate(about:blank, 0, , , ) destroy inv_script_obj close(this)这个步骤看起来多余但实际非常管用。不释放资源的话用户开着系统一整天反复打开关闭内嵌页面窗口内存占用会越来越大最后界面卡顿到点不了按钮。4. 完整实操做一个内嵌报表加载器4.1 需求与界面设计为了把上面的知识点串起来我拿一个实际做过的需求当例子医院信息系统里要给医生工作站加一个“手术统计报表”页面数据展示用ECharts但入口和权限在PB的老系统里要求医生点击菜单后在PB窗口内打开页面并且把当前登录医生的科室传过去页面按科室过滤数据。界面设计很简单一个窗口w_report_browser顶部是一个静态文本显示当前报表名中间放Web Browser控件ole_web底部是两个按钮——“刷新数据”和“打印报表”。整体界面保持PB风格不需要花哨的UI客户要的是稳定。4.2 加载页面并回传参数窗口Open事件里读取配置文件URL拼接上查询参数然后导航到报表页面。// w_report_browser.Open事件 string ls_url, ls_dept_code, ls_user_code ls_url gnv_config.GetValue(ReportServer, base_url) ls_dept_code gnv_pub.dept_code ls_user_code gnv_pub.user_code // 拼接参数页面根据参数按科室过滤 ls_url /surgery_statistics.html?dept ls_dept_code user ls_user_code ole_web.object.Silent : true ole_web.object.Navigate(ls_url, 0, , , )这里有个细节参数传递尽量别用POST因为Navigate的PostData参数处理起来比较别扭而且URL参数方式在做页面调试时更方面——你直接在浏览器里打开带参URL就能看到和PB里一致的效果。如果参数里有中文或特殊字符记得先做URL编码PB里有UrlEncode函数或者用escape函数处理否则页面收到的参数会出现乱码。4.3 刷新与打印功能实现“刷新数据”按钮的逻辑不复杂就是调用页面里的刷新函数。但注意报表页面往往有自己的查询条件区域刷新应该保留用户当前的选择而不是把页面重新加载一遍。所以更合理的按钮交互是让页面自己负责刷新PB只触发事件。// cb_refresh.clicked事件 string ls_js ls_js javascript:doRefresh(); ole_web.object.Navigate(ls_js, 0, , , )“打印报表”要分两种处理。如果页面是纯前端绘制比如ECharts图表导出图片那PB侧调用ExecWB实现浏览器打印这种方式打印的是整个页面包含按钮、图表、标题但它的打印预览对话框是浏览器自带的样式可控性差。很多报表场景其实更希望走“调用页面里的打印函数页面自己控制打印模板”的路子。// cb_print.clicked事件 // 方式一浏览器原生打印 ole_web.object.ExecWB(6, 1, 0, 0) // OLECMDID_PRINT 6 // 或者方式二让页面里的JS处理 string ls_js ls_js javascript:doPrint(); ole_web.object.Navigate(ls_js, 0, , , )两种方式我都用过更推荐方式二。因为方式一的浏览器原声打印会打出整张页面包括顶上那个“手术统计报表”的标题和按钮位置往往会有空白页或者页眉页脚问题调起来很费劲。页面内部用CSS的media print来定制打印样式干净得多。4.4 数据窗口打印预览的补充说明热词里有一条“pb的数据窗口有printpreview()函数吗”很多人其实是在做报表时搞混了数据窗口和Web报表的分工。这里我顺着说清楚PB的数据窗口确实有打印预览能力但方法名是PrintPreview()不是printpreview()而且在调用前需要设置数据窗口的Print.Preview属性为True。// 数据窗口打印预览标准写法 dw_report.Object.DataWindow.Print.Preview : True dw_report.PrintPreview() // 退出预览模式 dw_report.Object.DataWindow.Print.Preview : False数据窗口适合打印那种规规矩矩的表格单据比如检验报告单、处方单Web报表适合带图表、视觉化展示的场景。在同一个系统里两者配合使用的思路是数据窗口处理格式固定的单据Web页面处理可视化分析报表各司其职。我不建议在一个场景里混用尤其不要试图在Web页面里打印数据窗口的内容那会变成一个无尽的坑。5. 常见问题与排查实录5.1 页面空白或加载不出来嵌入式浏览器的第一大坑就是页面空白。原因从常见的可能性依次排查第一URL不通。这个最多见。开发机访问正常但客户内网访问不了服务器的80端口或者8080端口。先让客户在终端机器上用IE手动打开地址试试能开再谈组件问题。第二脚本错误导致白屏。很多前端框架在IE内核下运行会抛错而错误被吞掉之后渲染就中断了。我前面说的Silent : true只是不弹错误框但不能解决真正JS出错的问题。排查时要临时把Silent改成False让错误框弹出看具体是什么错误。常见的是浏览器不支持某些ES6语法或CSS3特性。第三ActiveX控件本身没有成功实例化。窗口设计器里能拖进来不代表运行时一定成功特别是在开发者用64位PB编译、目标机器是32位系统或者反过来的时候。虽然Web Browser控件是系统级的但OLE实例化偶尔也会出幺蛾子。解决办法是在代码里加一个OLE实例化成功的判断。// 检查OLE对象是否可用 if isnull(ole_web.object) then messagebox(错误, 浏览器组件加载失败) end if第四兼容性视图设置。IE内核默认有兼容性视图如果你在开发时加了meta标签指定IE版本部署时也要确保目标机器的注册表或者组策略没有强制企业模式否则会走低版本渲染模式页面完全变形。5.2 页面里的弹窗被拦截或显示异常Web页面上常见的window.open弹窗在PB嵌入式浏览器里经常会被当成“弹出窗口”拦截虽然它没有独立的弹出窗口拦截器但很多页面逻辑里用window.showModalDialog或者window.open打开的对话框行为会变得难以预测。有些是根本打不开有些是打开了但没有模态效果用户可以乱点。这个问题的根治思路是不要在页面上使用依赖弹窗的交互改为页面内部用div遮罩来实现“伪弹窗”。因为嵌入式浏览器的弹窗本质上是走了系统的IE窗口它在PB窗口的Z轴顺序、焦点控制上都很难完美。我在项目里会明确要求前端团队内嵌页面禁止使用window.showModalDialog、禁止window.open有弹窗需求一律用自绘Modal组件。如果实在没法改前端可以尝试在NewWindow2事件里做处理把新窗口导航到当前控件但那个做法很麻烦还容易出现多个页面互相覆盖导航的问题我只能说能实现但不推荐。5.3 内存只增不减、窗口关闭卡死这是内嵌网页最容易被诟病的问题。表面现象是系统开几天后越来越卡内存占用持续上升。原因基本是页面里有定时器、动画、WebSocket连接没有正确销毁加上PB关闭窗口时没有释放OLE资源。这一块我在第3.3节提到过资源释放是关键。我再补充一个实战技巧如果页面里用了WebSocket或者SSE长连接PB关闭窗口前最好先通知页面主动断开连接不然即使PB这边释放了资源服务端那边可能还挂着失效的会话。我做一个项目时页面里用一个WebSocket接收检查报告推送用户直接关窗口不通知页面断开服务端会话堆积了几百个把服务器搞崩了。后来在窗口Close事件里先调用javascript:beforePageClosed();通知前端清理再Navigate(about:blank)、销毁对象这个问题就解决了。5.4 兼容性与性能调优心得最后说一点基于实际维护经验的心得吧。PB项目往往生命周期非常长一个HIS系统用个十年八年很正常。嵌入式浏览器组件这种方案虽然能用但每一次操作系统大版本升级、每一个前端框架版本迭代都可能带来新的兼容问题。我的应对策略是对外层做厚度隔离。什么意思就是在PB和具体页面之间加一个“适配层”不要让PB代码直接和页面里的具体JS函数名耦合。PB调页面统一走PBInvoke(action, param)这个入口页面回传数据统一走window.external.PBHandle(type, data)。这样上来讲后期页面改版、换前端框架、甚至换WebView组件PB侧的改动都能控制在很小范围内。我也遇到过项目把内嵌IE升级成WebView2的情况因为适配层设计得干净PB侧只换了控件初始化和几个基础调用业务代码基本没动。做企业级应用最怕的就是业务代码和技术细节拧成一团。把技术选择的代价限制在局部模块里把业务逻辑和通信协议稳定下来这个系统的寿命就会长很多。这也是我做了这么多年PB项目最想分享的一条经验。本文还有配套的精品资源点击获取
