OLE Automation應用

'2001/10/02 酷小毅(永和)
大綱：
一、 從頭說起OLE Automation (套Word製作報表)image
二、 如何取得Word Automation所提供的服務
三、 如何控制Word新增表格
四、 如何將資料插入Word表格
五、 如何在同一份文件中複製相同的表格到下一頁
六、 完整範例程式列表

相信這是每一個程式設計師都有的經驗，辛辛苦苦寫完資料庫程式之後這些程式身邊還得伴隨著一個個漂亮至制式報表，老實說我還真沒什麼美感，要我在寫完程式之後還要去編排這些報表這實在是件辛苦的差事，若能透過Automation請Word幫我們製作報表可以減輕不少的負擔，再加上Word 所建立出來的Template Files可以Reuse，只要有Microsoft Word的機器即可開啟編輯，現在要找到沒有Word的機器我想也很難找到了，以前有前輩以Delphi為範例介紹，現在小弟我就以Visual Basic為範例介紹，二話不說，我們開始吧。
如何取得Word Automation所提供的服務
下圖為建立Word Automation Application所需的程式碼，小弟我以Visual Basic為範例介紹，二話不說，我們開始吧
如何取得Word Automation所提供的服務
下圖為建立Word Automation Application所需的程式碼，小弟我以CreateObject為範例介紹，當然你也可以使用VB最簡單的方式直接引用TypeLib方式，不過這樣此程式就只能固定的被使用在所勾選的特定Word版本，因為你如果直接勾選VB會將他所使用到該元件(Component)的相關 TypeLib一起Compile在執行檔中，無形中就寫死了，一般如果是特定元件的使用(如常常可能會修改，但不改介面)我會建議以原生物件的呼叫方式，不過當然這樣就享受VB整合是開發式環境 (List Properties Method)的好處了，以我的習慣會先引用，然後待開發完成之後再將所有宣告改成Object，改以CreateObject建立原生物件不彷提供給讀者做參考。在上面的程式碼也很簡單，我先以On Error Resume Next加以宣告，若建立Word發生錯誤則秀出建立Word發生錯誤訊息。
image
如何控制Word新增表格
1.          宣告共用邊數
下方我們在Module中宣告Public的Word Application以及整個程式會使用到的相關共用變數。
。
image
2.          新增一個文件及取得資料庫資料表列數
下方程式會先在目前create的Word中建立一份新文件，第二行會設定文件預設的擁有者，ColCount與RowCount分別會取得筆者SQL Server中Table的資料欄位數目與資料筆數作為我們要新增這個Word表格的依據。
image
3.          新增表格到Word中
為了讓表格建立時是出現在文件的最上方，我們必須新取得文件上方的座標，讀者應該看出第一行的(Start:=0, End:=0)所代表的意義，接著下一行在這個Range中建立這個資料表大小的表格。
image
如何將資料插入Word表格
1.          插入資料到Word中
要將資料插入Word非常的簡單，相信讀者一看就知道它會寫入目前ActiveDocument下的第一個Table的Cell(Row, Column)中，資料來源就看你如何變化了，也可以從文字檔中或是某程式的執行結果中，本文則是以資料庫中的資料表貼的資料上Word表格為範例，比較重要的地方是.Tables.Item(Index)，若文件有多頁時可以決定要插入第幾頁的表格。
image
2.          如何使Word結束時不存檔
每當我們要關閉程式時Word總是會問你要不要存檔，解決方法如下，使用wdDoNotSaveChanges常數，也可寫成如第二行。
image
如何在同一份文件中複製相同的表格到下一頁
1.          如何選擇文件中的所有內容
要複製表格及文件的所有資料第一步當然要先選擇這個文件的所有內容，有一點要注意的是選擇前您必須只保留要複製的那一頁就好，一旦複製就是複製整個文件所有的內容，包括Word中11種類型的文字。
image
2.          如何複製文件並建立相同的內容至下一頁
以前筆者曾經遇到一個問題，User需要列印一整串的資料，如財務報表，它可能需要一次印一月到十二月的資料，剛好又是每月一個頁面，而每個頁面的表格又相同，而User又想一次貼完所有一到十二月資料以便預覽時能在一份文件中預覽十二個頁面的資料，這時我們就必須能夠動態的在這個Word 範本檔中新增User所需的頁面資料，可能是一到五月或三到七月等等….因為我們絕不可能在一個範本檔中一開始就儲存固定的頁面，這樣未免太沒有彈性了，筆者用底下的方法解決這個問題，不過在貼上實際得先複製，因為範本檔一開始只會有一頁。
(1).如何將游標移至文件的最底端
image
(2). 取的目前文件的總頁數
當我們複製完第一頁的資料之後就必須進行資料的處理，得知User的資料共有多少個月份(多少個頁面)，以便貼上相同的表格至該頁面，而再做這些處理時有時我們必須知道目前文件中一共有多少頁，下面為取的的方法。
image
(3). 如何判斷Word是否增加新頁
在我們貼上新頁之前必須使Word增加一個新頁，底下筆者提供兩種做法，第一種做法會將游標移至底端並判斷頁數是否加一，若加一則貼上文件內容，你可以跑回圈計算頁數動態產生，讀者應看出他利用目前Tables.Item(index)下的Application物件的Selection下的TypeParagraph方法，執行這個方法就像在Word中直接按下Enter鍵件一般，Selection物件則是Word文件提供的集合物件，此物件功能非常多，在文件上的文字選取範圍段落或設定都可以利用這個物件來完成，有興趣了解這個物件可在Word的VBAOnLineHelp有非常詳細的說明這邊就不深入討論，不過筆者認為利用Enter鍵換頁這其實並不是很好的做法，筆者在提另一種做法給各位參考，程式碼比較短，效能也比較快。
image
讀者發現第二種做法程式碼只要四行就完成了，利用選取物件Paragraphs物件設定新增的一個Range(新增一個空白選取範圍)，接著一樣將游標指向文件的最頂端，把剛才Copy到剪貼簿的表格資料貼上去就算成功複製一個新頁面而擁有相同的表格了。
image
(4). 設為預覽列印模式
要列印當然要能夠自動設為預覽列印模式User才能夠看的清楚它所要印的文件內容，方法如下。
image
(5). 設定預覽時顯示的比例
Word的預設的預覽列印可能會讓User看不清楚字，所以當然要設定一下預覽的比例。
image
3.          範例程式執行畫面
下圖為範例程式的執行畫面，所使用的資料表共有四個欄位(ID_NO, NAME, ADDRESS, EMAIL)
image
4.          Create TABLE SQL語法
由於本文中Word表格中的資料來源是Microsoft SQL Server，下面提供建立所使用Table的SQL Command。
image
5.          Form完整範例程式列表
image
 image
6.          Module完整程式列表
image

留言

張貼留言

這個網誌中的熱門文章

什麼是 gRPC ？

圖片
圖片取自： https://grpc.io/docs/guides/ gRPC 是什麼？能吃嗎？ 在安裝了 .NET Core 3.0 之後，眼尖的朋友應該會發現，在新增 ASP.NET Core 網頁類型專案裡，會看見一個 gRPC Service 類型的專案，其實它也不是什麼很新的東西，早在十多年前 Google 就使用這樣的 RPC 協定進行一些大量的可靠性微服務的存取，聽到這，難道現有的 Web API 不可靠嗎？其實不是的，它主要用在移動設備等提供高效簡單且跨平台的通訊與熱插拔的驗證機制。 gRPC 的運作原理 gRPC 顧名思義，是種基於 RPC 的通訊協定，不同於 Web API 走的傳統 HTTP 基礎協定，它有點像是 Socket ，但應該說是基於 Socket， 或精確地來說它是基於 HTTP/2 的協定 ，gRPC 是種協議緩衝協定，它必須事先定義 IDL (Interface Definition Language) 描述檔，看到 IDL 對於一些熟悉 COM／DCOM 的朋友一定非常的熟悉，對！沒錯！就是類似的東西！但，這邊的 IDL 是用一種副檔名為 .proto 檔案來是先定義在分散式環境中，要傳輸的序列化結構資訊，當然它也可以跟 JSON 一起使用。 也就是說，要使用 gRPC 您必須先定義 .proto 協議，然後透過 Compile 的支援，編譯成特定語言框架。而很高興的是，C# 也支援了，然而其實根據官方的資料顯示，C# 應該在 .NET Core 2.1 開始就支援了，只是到了 .NET Core 3.0 才有樣版的支援。 而使用 gRPC 的協議緩衝區的服務可以做到 Stub 的機制，也就是說，它就像是許多 RPC 一樣，Client 在呼叫 Server 端時，其實是對 Stub 進行叫用，Stub 在這就像個緩衝區一般，但更細部的說，應該是一個遠程服務的替身，這應該又讓許多熟悉 COM／RPC 通訊的朋友覺得熟悉了起來，是的！沒有錯。 在 .NET Core 3.0 裡使用 gRPC 目前支援 .proto 擴展為 gRPC 協議緩衝區的編譯器只有 .NET Core 了 ， 根據 Github 上的說明 .NET Framework 4.5+ 以上或 Mono 4+ 以上也可支援，而 gRPC 也完全的跨平台。要在 .
閱讀完整內容

什麼是 gRPC（二）- 來撰寫第一個 Hello World 吧！

圖片
前言 上一篇 什麼是 gRPC ，筆者大致介紹了 gRPC Service 的基本概念，這一次，我們就來小試一下身手，撰寫一個 Hello World （迷之音：嘗試新技術時，總是得先來一個 Hello World ～我不想違背這良好傳統阿阿阿阿） 使用環境 Visual Studio 2019 .NET Core 3.0.100-preview3-010431 開始進行 撰寫 gRPC 除了先準備好基礎環境、選定一種 作業系統／ 程式語言 Language 外、（Framework／SDK／Runtime）等環境備妥後，就可以開始撰寫， (1). 開始撰寫 gRPC 第一步就是先定義 .proto 協議了 上一篇筆者提到，gRPC 的 Server 與 Client 必須使用相同的協議才可進行溝通，一般來說，你應該使用 protoc.exe 編譯器先行編譯過 greet.proto 協議檔，並產出 C# 程式碼檔案後才可繼續，而在 Visual Studio 2019 裡，拜 MSBuild 之賜，已經有人預先寫好 .Target 檔案了 （什麼是 MSBuild ？什麼是附檔名 .Target 檔案可參考： MSBuild .targets 檔案 ） 筆者先撰寫一個 SayHelloWorld 方法如下： 在協議裡，除了在 service Class 撰寫要公開存取的方法外， 必須在提供『傳入訊息型態』、『回傳訊息型態』 ，這邊我先定義兩個 message，一個是『 HelloMyFirstgRPC 』、另一個是『 HelloMyReply 』 在撰寫 proto 協議檔時，建議先決定 message 回傳型態與傳入的型態，那麼 Visual Studio 2019 會有 InteillSense 的完整支援。不得不說 Visual Studio 2019 在 .proto 協議編輯上的支援已經算不錯了。 注意： 一般來說，Visual Studio 2019 會在背景裡自動編譯 .proto 協議檔案，但始有可能不會有任何提示，所以您也可以自行使用命令列工具進行手動編譯，如下圖，若編譯失敗會出現錯誤訊息，如下圖顯示 return 關鍵字錯誤： protoc.exe 編譯器 & 相關 MSBuild Tools 會隨著 NuGet 套件在 Vis
閱讀完整內容

常見的程式碼壞味道（Code Smell or Bad Smell）

圖片
常見的程式碼壞味道（Code Smell or Bad Smell） 圖片取自：https://www.slideshare.net/ElMahdiBenzekri/art-of-refactoring-code-smells-and-microservices-antipatterns 前言 究竟重複的程式碼要不要共用它？傳統的軟體開發上，重複的程式碼幾乎被視為罪惡的來源，但是它真的有多可怕？ 常見的 Code Smells The Dispensable （一些可有可無的） Lazy Class (冗員類別） 如果一個類很少使用它會增加代碼庫的複雜性，從而阻礙開發。這樣的類可能是不必要的，它的功能可以成為另一個類的一部分。 Data Class (只有資料的類別） 一個類別只有包含『資料』未包含Methods，也就是說並未包含行為，不具行為模式的類別代表該『實例』容易被【其他類別所操控】。 Duplicate Code (重複的程式碼) 如描述，這也是上次有分享在我的 FB 社團 軟體開發之路［德國資深架構師給新手的建議］ 中有產生非常熱烈討論，這在社團朋友提醒下想起 Refactor 重構一書裡曾提過 rule of three 法則， 這個法則的定義是這樣的，有時部分程式碼重複其實是允許的（不是說重複一定是是被允許的）而是在某些 Context 情境下，該程式碼有一段時間不會衍伸別的功能 或 需求一段時間不會異動、且如要將它 DRY 會產生的『複雜度』或『花費時間』遠高於預估的時間 或 不值得在目前這個專案的節骨眼上花費這個時間來做這件事，加上它 DRY 產生的複雜度偶後產生的維護成本【遠高於】不 DRY 的情況下的維護本，那麼，在這個時候，這個異動頻率【極低】的程式碼就不需要花費這個時間來 DRY 了！！ 因為重點在於，重構是需要『成本』的。(迷之音：DRY 是種抽象化阿~😎) 這讓我想起之前，大約在 2016 年左右，在 101 的樓上某金融業客戶，曾經做過一個專案，這個專案就是因為客戶 DMZ 環境的因素，我讓內網的 Webside 與 DMZ 的網站保留了部分重複的程式碼，因為這段程式碼終年不需要異動，我也懶得花這個時間，而我居然也忘了這記件事情了.. 哈哈 Orz 不過原歸正傳，我個人還是認為，其實適當
閱讀完整內容