簡介對于使用 Borland Delphi 3 至 7.1 的開發(fā)者Report Machine 2.6 是一款成熟的報表生成工具。這套組件支持在 IDE 內(nèi)直接設(shè)計多列、分組、匯總及自定義樣式并可接入數(shù)據(jù)庫、XML、CSV 等數(shù)據(jù)源幫助項目快速產(chǎn)出高質(zhì)量打印文件。壓縮包共 488 個文件、2.1MB以 139 個 pas 源碼、119 個 dcu 已編譯單元和 71 個 dfm 表單為主體配合 res 資源、ini 配置、rc 腳本等既便于閱讀運行邏輯也可直接安裝使用。值得關(guān)注的是程序擁有 100% 開放源碼開發(fā)者不僅能免費用于自身項目還可按需修改或擴展功能尤其適合有特殊報表格式要求或想深入理解報表引擎實現(xiàn)的人群。包內(nèi)還附帶 MAKEALL、MK、MKDLL 等批量構(gòu)建腳本以及面向不同 Delphi/C Builder 版本的 bpk、dpk 工程文件版本切換與重新編譯都很方便。目前已有 287 人學(xué)習或下載對正在維護老項目或需要輕量離線報表方案的工程師來說這套體積小巧、源碼完整的歷史工具仍具備很高的參考和實用價值。1. Report Machine 2.6 還在 C/S 項目里值錢一款能打的老牌報表組件Report Machine 2.6 的年紀比很多開發(fā)者的工齡都大但到了今天它在國內(nèi)大量 C/S 管理信息系統(tǒng)里依然被用于財務(wù)打單、倉儲備貨、業(yè)務(wù)對賬這些“最后兩公里”的輸出環(huán)節(jié)。它解決的核心問題是在 Delphi/C Builder 項目里用最小成本把數(shù)據(jù)集變成一張能打印、能導(dǎo)出、能存檔的正式報表。適合三類人看這篇筆記正在維護存量項目、被要求加報表卻不想動三層架構(gòu)的開發(fā)者剛接手項目、需要判斷這套報表還能不能繼續(xù)用的新人以及在做技術(shù)選型時糾結(jié)“舊組件繼續(xù)用還是推倒重寫”的負責人。它不新但穩(wěn)定、輕、社區(qū)踩坑記錄足夠多這本身就是選型時值得認真權(quán)衡的理由。2. 先摸清 RM 2.6 的運行機制設(shè)計器、腳本引擎與三段式渲染2.1 三層架構(gòu)拆解Engine、Report 對象與 DataSet 各管什么用 RM 2.6 之前先理解它的三個層次否則后面調(diào)試起來會感覺全是黑匣子。最底層是報表引擎一般以 rmEngine 組件形式存在。它負責把報表對象的描述——行列坐標、字體、邊框、單元格內(nèi)容、表達式——轉(zhuǎn)換成實際的打印坐標和導(dǎo)出指令。開發(fā)者平時不直接碰它但它決定了所有渲染環(huán)節(jié)的行為。第二層是面向開發(fā)者的報表對象最常用的是 rmGridReport 和 rmLibReport。rmGridReport 是網(wǎng)格型報表適合結(jié)構(gòu)規(guī)整的明細表、分組表rmLibReport 是自由版式適合單據(jù)、票據(jù)、標簽這類需要元素隨意擺放的場景。兩個對象最終都掛在窗體或數(shù)據(jù)模塊上它們在設(shè)計器里編輯在運行期被驅(qū)動。第三層是數(shù)據(jù)橋接RMDataSet、RMDBDataSet 這類組件負責把 BDE、ADO 或自定義數(shù)據(jù)源里的記錄集交給報表對象。這里有個新手容易犯的誤解RM 2.6 的報表文件不只是布局描述它把數(shù)據(jù)源引用和腳本一起打包在 .rmd 文件里。所以運行期加載模板后如果客戶機的數(shù)據(jù)源名稱、字段名對不上預(yù)覽界面會直接白屏而且不報具體錯誤這是它年代久遠、錯誤提示不夠友好的典型表現(xiàn)。報表從加載到輸出的完整生命周期可以概括成三步LoadFromFile 讀入模板Initialize 根據(jù)當前數(shù)據(jù)集重建行列結(jié)構(gòu)PreviewModal 渲染預(yù)覽。我一般建議把“加載模板-綁定數(shù)據(jù)-初始化-預(yù)覽/導(dǎo)出”固定成一套操作順序所有報表都按這個順序走后面排查問題時思路會清晰很多。2.2 兩種報表對象的差異rmGridReport 與 rmLibReport 的選型邏輯很多剛接觸 RM 2.6 的人在兩種報表對象之間拿不準其實判斷標準很簡單內(nèi)容能不能規(guī)整地落成行列。對比維度rmGridReportrmLibReport布局模型網(wǎng)格行列驅(qū)動自由坐標與帶區(qū)驅(qū)動典型場景明細表、分組表、匯總表單據(jù)、發(fā)票、標簽、排班表數(shù)據(jù)組織每一行綁定記錄對象綁定位置隨意腳本復(fù)雜度較低關(guān)注行號與單元格較高關(guān)注對象坐標與事件導(dǎo)出兼容性PDF/Excel 導(dǎo)出更穩(wěn)定自由版式導(dǎo)出易錯位具體到選型我一般遵循一條原則只要內(nèi)容能落成行列優(yōu)先用 rmGridReport。它在導(dǎo)出 PDF 和 Excel 時幾乎不需要額外處理列對齊而 rmLibReport 雖然版式靈活但導(dǎo)出時容易因為字體寬度、邊距計算差異出現(xiàn)對象錯位調(diào)試成本高一個量級。反過來如果做的是送貨單、報銷單這種“一個單據(jù)占一頁紙、各個字段散布在固定位置”的版式硬用網(wǎng)格報表去拼反而別扭這時候 rmLibReport 才是對的選擇。一個細節(jié)值得注意rmGridReport 的列數(shù)、行寬在設(shè)計器里已經(jīng)確定但運行期數(shù)據(jù)記錄數(shù)變化后需要調(diào)用 Initialize 重新計算“這個報表實際要打印多少行”。如果省掉這一步預(yù)覽時容易出現(xiàn)多頁空白或末頁數(shù)據(jù)行被截斷。2.3 報表腳本到底寫了什么事件鉤子決定執(zhí)行順序RM 2.6 的腳本是類 Pascal 語法掛在報表對象的事件上。它不算完整的編程語言但支持變量、函數(shù)、循環(huán)和基本對象訪問足夠應(yīng)付分組、累加、動態(tài)顯隱這些需求。常見事件按執(zhí)行順序排列Initialize報表初始化。在這里做全局變量清零、數(shù)據(jù)集綁定、初始參數(shù)設(shè)置。BeforeRow / AfterRow行級鉤子分別在每行處理前后觸發(fā)。分組判斷、累加器更新都寫在這里。BeforePrint頁級鉤子在每一頁真正輸出前觸發(fā)。頁腳內(nèi)容、動態(tài)顯示隱藏對象在這里控制。OnExport / BeforeExport導(dǎo)出前的干預(yù)點適合做字體替換、導(dǎo)出文件名拼接。下面是一個典型的 Initialize 腳本做累加變量清零procedure rmGridReport1Initialize(Sender: TObject); begin // 全局累加變量在報表重建時清零 totalAmount : 0; // 同時把報表標題里的日期刷新到當前系統(tǒng)時間 RMGridReport1.TextTo(0, 0, 統(tǒng)計日期 DateToStr(Date)); end;這段腳本的關(guān)鍵在于 Initialize 觸發(fā)時機它在數(shù)據(jù)集綁定之后、分頁計算之前執(zhí)行。也就是說此刻數(shù)據(jù)集已經(jīng)打開但報表還沒開始逐行處理適合做“整個報表只執(zhí)行一次”的初始化工作。TextTo 的作用是把文本寫入指定坐標的單元格參數(shù)分別是列號、行號、內(nèi)容如果不調(diào)用 InitializeTextTo 寫入的內(nèi)容可能被后續(xù)的行刷新機制覆蓋。腳本編譯失敗時運行期預(yù)覽會彈出腳本錯誤框并定位到具體行號這是全流程里最有價值的排錯信息。我見過不少同事在腳本報錯后回去翻設(shè)計器屬性其實應(yīng)該先看錯誤框指向的行號那才是問題根源。3. 把第一張報表跑起來安裝、最小示例與兩種交付方式3.1 環(huán)境準備組件的安裝順序決定你后面省不省事在 Delphi 里裝 RM 2.6 不算難但順序錯了會消耗大量時間。我的固定步驟如下第一步把組件包解壓到不含中文、不含空格的目錄比如 D:\Components\RM2_6。老組件對中文路徑的兼容非常玄學(xué)目錄帶中文時編譯期可能找不到 DCU 文件報錯信息又模棱兩可。第二步在 IDE 的 Component Install Packages 里添加運行期包和設(shè)計期包。先裝運行期包再裝設(shè)計期包順序反了可能導(dǎo)致組件面板出現(xiàn)重復(fù)項或圖標缺失。裝完后重啟 IDE這一步很關(guān)鍵因為設(shè)計期包的注冊信息需要 IDE 重啟后才能生效。第三步把組件目錄下的 Lib 子目錄加入 Tools Environment Options Library 的搜索路徑。否則編譯工程時會出現(xiàn)找不到 RM_*.dcu 的錯誤。第四步新建一個窗體確認組件面板多了一個 RM 頁拖一個 RMGridReport 到窗體上。雙擊組件能打開設(shè)計器說明安裝成功。安裝完成后我建議先做一個最小驗證新建一個空工程拖一個 RMGridReport在設(shè)計器的數(shù)據(jù)集屬性里隨便綁定一個本地表預(yù)覽一次。這一步花不了五分鐘但能把“組件沒裝好、設(shè)計器打不開、腳本引擎異?！边@三類環(huán)境問題在寫業(yè)務(wù)代碼之前全部暴露出來。3.2 最小示例從外部模板跑通“加載-綁數(shù)據(jù)-初始化-預(yù)覽-導(dǎo)出”環(huán)境沒問題后按下面這段代碼建立一個最小可運行示例。它的作用是從外部 .rmd 模板加載報表綁定 ADO 數(shù)據(jù)集預(yù)覽并導(dǎo)出 PDFprocedure TForm1.Button1Click(Sender: TObject); var ReportPath: string; begin // 模板放在 exe 同級的 templates 目錄下 ReportPath : ExtractFilePath(Application.ExeName) templates\rpt_demo.rmd; // 1. 指定模板路徑并加載 RMGridReport1.ReportName : ReportPath; RMGridReport1.LoadFromFile; // 2. 綁定數(shù)據(jù)集必須在 Initialize 之前完成 RMGridReport1.DataSet : ADODataSet1; ADODataSet1.Open; // 3. Initialize 會根據(jù)當前數(shù)據(jù)行數(shù)重建報表結(jié)構(gòu) RMGridReport1.Initialize; // 4. 模態(tài)預(yù)覽由用戶在預(yù)覽窗口里決定打印或?qū)С?RMGridReport1.PreviewModal; end;這段代碼的順序是硬約束先 LoadFromFile、再綁數(shù)據(jù)集、再 Initialize、最后 PreviewModal。如果數(shù)據(jù)集還沒打開就調(diào)用 Initialize報表會按零行數(shù)據(jù)計算分頁預(yù)覽結(jié)果是一張空表如果 LoadFromFile 之后不調(diào)用 Initialize數(shù)據(jù)集換了但報表的行數(shù)還是模板里保存的舊值最典型的表現(xiàn)是“預(yù)覽第一頁數(shù)據(jù)是對的后面全是空行”。參數(shù)說明ReportName 傳入的是完整路徑這里用 ExtractFilePath(Application.ExeName) 拼出當前程序所在目錄是為了避免路徑寫死導(dǎo)致部署到其他機器時報“無法打開模板”。模板加載成功后PreviewModal 是阻塞式調(diào)用用戶關(guān)掉預(yù)覽窗口后代碼才會繼續(xù)往下走如果不想阻塞可以換 Preview 調(diào)用但那樣打印任務(wù)和界面會同時進行容易觸發(fā)句柄沖突我一般不用。如果要跳過預(yù)覽直接導(dǎo)出 PDF可以改成RMGridReport1.ExportToPDF(OutputDir rpt_demo.pdf, True);其中最后那個布爾參數(shù)表示“導(dǎo)出完成后是否立即用系統(tǒng)默認 PDF 閱讀器打開”。正式環(huán)境里我更習慣傳 False因為客戶機上不一定裝了 PDF 閱讀器自動打開反而會彈出錯誤對話框。3.3 兩種交付形態(tài)內(nèi)嵌模板與外部 .rmd 的取舍RM 2.6 的報表模板有兩種存放方式取舍不同直接影響后期維護成本。第一種是模板內(nèi)嵌在窗體或數(shù)據(jù)模塊的 DFM 里。做法是設(shè)計器里設(shè)計完成后不調(diào)用 LoadFromFile直接讓組件使用設(shè)計時保存的模板。優(yōu)點很明顯exe 單文件交付不存在模板文件丟失的問題缺點是每次修改報表樣式都要重新編譯整個程序?qū)嵤┤藛T在現(xiàn)場改不了任何布局只能干等開發(fā)發(fā)新版。第二種是模板作為獨立 .rmd 文件放在程序目錄下。運行期通過 ReportName 指定路徑加載。優(yōu)點是修改版式只替換文件不需要重新編譯實施人員經(jīng)過簡單培訓(xùn)就能調(diào)整表頭、列寬、字體缺點是要處理好三件事路徑一致性、版本覆蓋、權(quán)限?？蛻魴C上模板文件被殺毒軟件隔離、舊模板覆蓋新模板導(dǎo)致樣式回退都是實際發(fā)生過的問題。我的常規(guī)做法是開發(fā)驗證階段全部用外部 .rmd 文件方便反復(fù)調(diào)整驗證通過后把最終模板嵌入到程序資源里隨 exe 發(fā)布輸出端用 LoadFromResource 加載避免客戶現(xiàn)場丟文件。這樣兼顧了開發(fā)效率和交付可靠性但犧牲了一點現(xiàn)場改樣式的靈活性。如果項目里實施人員確實需要經(jīng)常調(diào)樣式那就保留外部文件方案同時部署一個模板版本管理工具覆蓋前自動備份舊文件這就是后悔藥。4. 導(dǎo)出 PDF/Excel 的避坑清單字體、合并單元格與五個高頻坑4.1 導(dǎo)出器的工作流程為什么“先初始化再導(dǎo)出”是底線RM 2.6 的導(dǎo)出模塊在內(nèi)部把報表引擎的頁描述逐頁翻譯成目標格式。PDF 導(dǎo)出器直接解釋頁面坐標Excel 導(dǎo)出器則通過單元格接口逐格寫入。這意味著一個事實導(dǎo)出效果嚴重依賴 Initialize 之后的內(nèi)存頁面模型。如果數(shù)據(jù)沒刷新就導(dǎo)出導(dǎo)出文件里可能就是上一次數(shù)據(jù)的殘留如果報表對象內(nèi)部還處于“設(shè)計態(tài)”而非“運行態(tài)”導(dǎo)出的 PDF 可能是空頁。我一般在導(dǎo)出前固定做三件事// 先加載模板 RMGridReport1.ReportName : rpt_sales.rmd; RMGridReport1.LoadFromFile; // 再綁定數(shù)據(jù)并初始化 RMGridReport1.DataSet : ADODataSet1; RMGridReport1.Initialize; // 最后執(zhí)行導(dǎo)出 RMGridReport1.ExportToPDF(rpt_sales.pdf, False);這三段順序里Initialize 是導(dǎo)出前的最后一道門檻。它同時重算行數(shù)、列寬、分頁和字體映射跳過它導(dǎo)出的文件大概率是“半成品”。尤其在批量導(dǎo)出多個報表時每個報表都要獨立走一遍這套流程不能圖省事共用一個報表對象連續(xù)導(dǎo)出不同模板。4.2 PDF 導(dǎo)出中文字體映射與頁邊距設(shè)置PDF 導(dǎo)出最典型的問題是中文變成方塊。原因不復(fù)雜2.6 的 PDF 導(dǎo)出器在生成文件時要把字符映射成字體輪廓如果找不到能覆蓋漢字的系統(tǒng)字體就會退化為占位符。預(yù)覽界面用的是 Windows GDI 字體顯示正常導(dǎo)出器直接走字符映射字體不匹配就露餡。處理方法有兩層。第一層在設(shè)計器里解決報表里所有文本對象的字體統(tǒng)一設(shè)置為系統(tǒng)中文字體最常見的是宋體。注意字體名必須和客戶機系統(tǒng)字體完全一致大小寫都別錯否則導(dǎo)出器同樣不認識。第二層在代碼里兜底用字體替換函數(shù)把報表里的自定義字體統(tǒng)一替換成中文字體// 把報表中名為 MyFont 的字體統(tǒng)一替換為宋體 RMGridReport1.ReplaceFont(MyFont, 宋體);ReplaceFont 常見做法是遍歷報表內(nèi)所有文本對象當某個對象的字體名匹配第一個參數(shù)時改成第二個參數(shù)。這里有個易錯點ReplaceFont 必須在 Initialize 之后調(diào)用否則報表重建時字體又被重置回模板里的默認值。執(zhí)行完替換后建議補一句 Initialize讓替換結(jié)果固化到頁面模型里。頁邊距問題也常出現(xiàn)在 PDF 導(dǎo)出中。RM 2.6 的 PDF 頁面尺寸默認沿用當前打印機的紙張設(shè)置如果客戶機沒有安裝設(shè)計時用的打印機PDF 的紙張大小可能退化成 Letter 而不是 A4導(dǎo)致右側(cè)或底部多出空白。解決方法是顯式指定紙張RMGridReport1.PageSetup.Orientation : poLandscape; RMGridReport1.PageSetup.PaperSize : 9; // 9 在多數(shù)版本里對應(yīng) A4注意 PaperSize 的枚舉值在不同版本里不一定相同寫代碼前先在當前安裝包里查一下常量定義表別直接抄網(wǎng)上的數(shù)值。橫向報表尤其要確認 Orientation這是后面第 4.4 節(jié)里會展開的坑。4.3 Excel 導(dǎo)出合并單元格、列寬與大數(shù)據(jù)量導(dǎo)出Excel 導(dǎo)出是另一個重災(zāi)區(qū)。RM 2.6 的 Excel 導(dǎo)出器按單元格逐格寫入對合并單元格支持相當有限跨頁表頭的合并區(qū)域在導(dǎo)出后經(jīng)常被拆成斷裂狀態(tài)列寬也只能保留整數(shù)精度導(dǎo)出后需要人工微調(diào)。我的處理原則客戶要“繼續(xù)加工數(shù)據(jù)”時導(dǎo) CSV客戶要“存檔看不改”時導(dǎo) PDF盡量不導(dǎo) Excel。如果項目里確實必須導(dǎo) xls那就接受兩個現(xiàn)實一是大數(shù)據(jù)量導(dǎo)出的時間可能是分鐘級兩三萬行數(shù)據(jù)卡上半分鐘是常態(tài)二是合并單元格的樣式還原度六成上下關(guān)鍵字段要多看一眼導(dǎo)出結(jié)果。此外導(dǎo)出 Excel 前最好關(guān)閉客戶機上的 Excel 進程否則導(dǎo)出組件與已打開的 Excel 實例交互時可能因為 OLE 沖突直接崩潰。這屬于典型的“環(huán)境坑”代碼里沒辦法規(guī)避只能通過操作規(guī)范來約束。4.4 五個高頻坑現(xiàn)象、原因、解決坑一PDF 里中文全部變成方塊現(xiàn)象報表在預(yù)覽窗口里一切正常點導(dǎo)出 PDF 后打開文件發(fā)現(xiàn)中文全成了方塊英文和數(shù)字正常。原因?qū)С銎髟谧鲎址成鋾r沒有可用的中文字體文本對象的字體名在客戶機上不存在或字體名稱大小寫不匹配。解決設(shè)計器里所有文本對象統(tǒng)一用系統(tǒng)中文字體導(dǎo)出前用 ReplaceFont 把自定義字體替換成宋體替換完成后再調(diào)用一次 Initialize 固化。格式化輸出后必須抽查首頁和末頁確認漢字輪廓正確?？佣?dǎo)出 Excel 非常慢甚至卡死現(xiàn)象一個兩三萬行的明細表導(dǎo)出 xls進度條長時間不動CPU 占用高Excel 彈“未響應(yīng)”。原因?qū)С銎髯叩氖?OLE 逐單元格寫入數(shù)據(jù)量越大寫入次數(shù)越多性能呈線性惡化實時殺毒還會逐格掃描進一步放大耗時。解決數(shù)據(jù)量大時先導(dǎo)出 CSV 或 TXT 讓客戶自己轉(zhuǎn)格式如果必須導(dǎo) xls把報表拆成多個小文件導(dǎo)出再用腳本合并不要在一個報表對象里硬撐?？尤龣M向報表打印/導(dǎo)出時右邊少一列現(xiàn)象設(shè)計器里表格完整打印機出紙后最后一列被截斷或者在 PDF 里最后一列跑到第二頁。原因圖紙方向還是縱向報表內(nèi)容寬度超過頁面可用寬度部分客戶機默認打印機紙張設(shè)成了 Letter可用寬度比 A4 窄。解決在代碼和設(shè)計器里同時把方向設(shè)為橫向并顯式指定 A4。注意設(shè)計器里的 Paper Setup 和代碼里的 PageSetup 必須保持一致否則代碼會在運行期覆蓋設(shè)計器設(shè)置。RMGridReport1.PageSetup.Orientation : poLandscape; RMGridReport1.PaperSize : 9; // 以當前安裝包的常量表為準坑四預(yù)覽總顯示上一次的數(shù)據(jù)現(xiàn)象同一個報表對象先打開數(shù)據(jù)集 A 預(yù)覽正常換成數(shù)據(jù)集 B 后預(yù)覽第一頁還是 A 的數(shù)據(jù)刷新無效。原因數(shù)據(jù)集換了但報表對象沒有重新 Initialize行列緩存、分頁數(shù)據(jù)都停留在上一次運行態(tài)。解決切換數(shù)據(jù)集后強制調(diào)用 Initialize。如果行數(shù)仍不對先把 RowsCount 置為 0 再調(diào)用 Initialize強制清空內(nèi)部行索引。這一步是解決“殘留數(shù)據(jù)”最直接的手段?？游暹B續(xù)導(dǎo)出多張報表頁碼不重置現(xiàn)象用同一個報表對象連續(xù)導(dǎo)出兩個 .rmd第二張 PDF 的第一頁頁碼顯示“第 3 頁”而不是“第 1 頁”。原因頁碼計數(shù)是引擎級變量報表對象切換數(shù)據(jù)后沒有同步重置頁碼在上次基礎(chǔ)上繼續(xù)累計。解決每張報表導(dǎo)出前獨立執(zhí)行一次 Initialize如果仍不重置查找腳本里有沒有手動修改頁碼變量的代碼特別是 BeforePrint 事件里對頁碼變量的賦值刪掉后在設(shè)計器里改用系統(tǒng)內(nèi)置頁碼字段。5. 真實報表的復(fù)雜度分組、交叉表與主子報表的落地做法5.1 分組小計與合計腳本鉤子里的累加和換頁業(yè)務(wù)報表十有八九要分組小計RM 2.6 里最常見的實現(xiàn)方式是在行級腳本鉤子里做累加和換頁判斷。下面這段腳本按部門編號分組部門切換時輸出小計并重新開始累加procedure rmGridReport1BeforeRow(Sender: TObject); var curDept, prevDept: string; begin // 讀取當前行與上一行的部門編號 curDept : RMGridReport1.GetCellValue(0, RMGridReport1.RowNo); prevDept : RMGridReport1.GetCellValue(0, RMGridReport1.RowNo - 1); // 部門發(fā)生變化時在上一組末尾寫出小計然后重置累加器 if curDept prevDept then begin RMGridReport1.TextTo(2, RMGridReport1.RowNo - 1, 小計: FloatToStr(subTotal)); subTotal : 0; RMGridReport1.NewRow; end; // 把當前行金額累加進小計 subTotal : subTotal StrToFloat(RMGridReport1.GetCellValue(2, RMGridReport1.RowNo)); end;參數(shù)說明GetCellValue 返回指定坐標單元格的文本內(nèi)容第一個參數(shù)是列號第二個是行號RowNo 是當前數(shù)據(jù)處理到的行索引TextTo 把字符串寫入指定單元格NewRow 在當前行下方插入一行。這段腳本的邏輯是“邊打邊判斷”遍歷每個數(shù)據(jù)行發(fā)現(xiàn)部門變了就把上一組的小計寫到上一組最后一行下面然后插入一行空白行把兩組隔開。subTotal 是腳本變量區(qū)聲明的全局變量需要在 Initialize 事件里清零否則多張報表連續(xù)預(yù)覽時累加器會帶著上一張的數(shù)據(jù)跑。這種寫法在報表行數(shù)不多、分組層級不深時夠用維護屬于“看得懂但有點碎”的水平。分組層級多、需要多級合計時我更建議在設(shè)計器里使用分組頭尾帶區(qū)在帶區(qū)的數(shù)據(jù)集屬性里指定分組字段運行期引擎會自動處理分組腳本只負責小計計算。把“換頁、插行”這類結(jié)構(gòu)邏輯交給帶區(qū)把“累加、格式化”留給腳本兩邊職責清楚后期改起來不費勁。5.2 交叉表把翻轉(zhuǎn)邏輯前置到 SQL報表只做渲染交叉表這類“行轉(zhuǎn)列”的需求RM 2.6 的交叉表組件能力有限動態(tài)列需要寫大量腳本做單元格拼接調(diào)試成本很高。我的建議是除非列數(shù)固定且業(yè)務(wù)不會再增加維度否則不要在報表里做交叉把翻轉(zhuǎn)邏輯前置到 SQL。固定列數(shù)的典型寫法SELECT dept_id, SUM(CASE WHEN MONTH(create_date) 1 THEN amount ELSE 0 END) AS m1, SUM(CASE WHEN MONTH(create_date) 2 THEN amount ELSE 0 END) AS m2, SUM(CASE WHEN MONTH(create_date) 3 THEN amount ELSE 0 END) AS m3 FROM biz_order GROUP BY dept_id這段 SQL 做的事情是把月份作為列方向維度用 CASE WHEN 把每個月的數(shù)據(jù)拆到獨立的 m1、m2、m3 列上。報表端只拿到一個規(guī)整的結(jié)果集直接在 rmGridReport 里加三列綁定字段即可腳本量趨近于零。報表端動態(tài)加列的寫法也能實現(xiàn)交叉表但腳本要處理列號自增、列標題動態(tài)寫入、數(shù)據(jù)行定位復(fù)雜度是指數(shù)級上升。我見過有人在腳本里寫了七十多行實現(xiàn)動態(tài)列交叉表結(jié)果隔兩個月業(yè)務(wù)加了兩個維度排錯排到凌晨。從那以后我的原則就是能在 SQL 里翻的絕不在報表里翻數(shù)據(jù)庫的擴展能力和調(diào)試手段都比老報表腳本強得多。5.3 主子報表主表定位變化時子表如何跟著變主子報表的經(jīng)典場景是訂單頭加訂單明細主表位置滾動時子表要同步顯示當前訂單對應(yīng)的明細記錄。RM 2.6 里我用的方案是 rmLibReport 做主表版式內(nèi)部嵌一個 RMGridReport 子對象子對象的定位跟隨主表記錄。關(guān)鍵代碼寫在主版的 BeforePrint 事件里procedure rmLibReport1BeforePrint(Sender: TObject); begin // 主表當前記錄定位完成后按主鍵過濾明細 ADOQueryDetail.Close; ADOQueryDetail.SQL.Text : SELECT * FROM order_detail WHERE order_id IntToStr(ADOQueryMaster.FieldByName(order_id).AsInteger); ADOQueryDetail.Open; // 明細數(shù)據(jù)集變化后子報表需要重新初始化 RMGridReportDetail.Initialize; end;參數(shù)說明ADOQueryMaster 是主表查詢order_id 是兩張表的主外鍵ADOQueryDetail 是明細查詢RMGridReportDetail 是嵌在 rmLibReport 里的子網(wǎng)格報表它在同一張單據(jù)頁面上固定占一塊區(qū)域區(qū)域大小在設(shè)計器里調(diào)好。為什么把這段邏輯放在 BeforePrint 而不是 Initialize因為 BeforePrint 在每一頁輸出前都會觸發(fā)此時主表記錄指針已經(jīng)定位到當前頁對應(yīng)的訂單子報表按這個主鍵過濾明細才能保證“這一頁打印哪個訂單子表就是哪個訂單的明細”。如果放在 Initialize 里只會執(zhí)行一次而后面的頁面在打印時主表記錄已經(jīng)滾動子報表內(nèi)容就錯位了。要注意的是子報表重新 Initialize 的代價是重新計算分頁如果明細行數(shù)特別多每頁都 Initialize 一次會有性能損耗。遇到這種情況我會把主表記錄分組輸出讓一個訂單的所有明細盡量集中在同一頁或連續(xù)幾頁減少重復(fù)初始化的次數(shù)。6. 交付前的三查清單把預(yù)覽、PDF、打印三個風險點一次摁住前面各章把 RM 2.6 的安裝、開發(fā)、導(dǎo)出和踩坑都過了一遍最后一章不聊新功能聊一個我已經(jīng)堅持了很多年的交付前三查清單。每次給客戶發(fā)版本前我會強制走一遍這三項檢查每項都只在容易翻車的地方設(shè)檢查點。檢查項檢查內(nèi)容典型問題表現(xiàn)紙張與方向設(shè)計器 PageSetup、代碼里的 PageSetup、客戶機默認打印機紙張橫向報表缺列、PDF 紙張變成 Letter字體映射PDF 導(dǎo)出后抽查首頁、中間頁、末頁的中文與數(shù)字中文方塊、字體重疊、數(shù)字錯位數(shù)據(jù)刷新連續(xù)打開多張報表確認每張第一頁數(shù)據(jù)都是新數(shù)據(jù)殘留上一次報表的數(shù)據(jù)、頁碼不重置紙張檢查不是單純在代碼里看一眼我通常在放行前用批量導(dǎo)出腳本把所有交付模板跑一遍 PDF重點看橫向報表和含窄列的報表。這里有一段我用于批量自檢的 Delphi 代碼procedure TSelfCheckForm.btnCheckClick(Sender: TObject); var i: Integer; begin // FileList 里是所有要交付的 .rmd 模板路徑 for i : 0 to FileList.Count - 1 do begin RMGridReport1.ReportName : FileList[i]; RMGridReport1.LoadFromFile; RMGridReport1.Initialize; RMGridReport1.ExportToPDF(OutputDir IntToStr(i) .pdf, False); end; end;這個循環(huán)不是自動化測試它只做一件事讓每一個模板在無人值守的情況下跑過“加載-初始化-導(dǎo)出”全流程。如果某個模板 PDF 生成失敗、導(dǎo)出來是空頁、或者內(nèi)容被截斷代碼會停在那一輪錯誤信息就是排查線索。我一般會順手把 PDF 文件按模板名重命名并編好序號方便對檢查結(jié)果關(guān)聯(lián)回原始報表文件。這輪自檢解決不了所有問題但能在發(fā)版前把兩大類問題攔下來模板文件結(jié)構(gòu)損壞、數(shù)據(jù)集綁定字段錯誤。字體和紙張這類和客戶機環(huán)境強相關(guān)的問題自檢代碼攔不住需要配合部署說明文檔在客戶現(xiàn)場裝完第一版時人工跑一張典型報表確認。我把字體和方向檢查寫進部署說明文檔的驗收一節(jié)讓實施人員照著打一張“驗收專用報表”只要這張表方向?qū)?、中文正常、?shù)據(jù)對就默認環(huán)境沒問題。印象最深的一次交付客戶現(xiàn)場打出來的所有單據(jù)都向右偏移折騰一晚上最后發(fā)現(xiàn)是客戶機默認打印機紙型設(shè)成了 Letter而報表設(shè)計器里一直是 A4 橫向。從那以后我每次交付報表都強制把三查清單走一遍先看紙、再看字體、最后看數(shù)據(jù)刷新。這三步看著笨但真的幫我擋掉過好多次低級事故多花十分鐘少返一次工。希望幫到你。本文還有配套的精品資源點擊獲取