大匠之風: 8月 2021

2021/08/25

從Excel操作問題來看工程師的通靈技能

前陣子在 Delphi.KTOP 看到一篇「請問 Excel AddSmartArt 第一個參數該怎麼設定」。

覺得操作 SmartArt 這點很有意思，這兩天才有時間認真看了這篇文章，一開始以為使用 Excel 的「錄製巨集」就可以搞定，但直覺認為回覆此內容時會得到「我早就已經知道」的結果。

因此決定一試 Excel 巨集功能，取得的 VBA 內容是：

    Call ActiveSheet.Shapes.AddSmartArt(Application.SmartArtLayouts( _
        "urn:microsoft.com/office/officeart/2005/8/layout/cycle1")).Select

就這麼短短一行，轉到 Delphi 上會是以下內容：

procedure TForm2.Button3Click(Sender: TObject);
var
  ExcelApp,
  ActiveSheet,
  oSALayout: Variant;
begin
  try
    ExcelApp := CreateOleObject('Excel.Application');
  except
    ShowMessage('建立EXCEL錯誤');
  end;

  ExcelApp.Visible := True;
  ExcelApp.WorkBooks.Add;
  ActiveSheet := ExcelApp.ActiveSheet;
  oSALayout := ExcelApp.SmartArtLayouts('urn:microsoft.com/office/officeart/2005/8/layout/hierarchy2');
  ActiveSheet.Shapes.AddSmartArt(oSALayout, 50, 50, 200, 200);
end;

卻得到以下結果：

看來樓主的問題內容並沒有說明完整，就來看一下 Excel Developer Docs 怎麼描述 SmartArtLayouts：

文件也就這麼一點點，沒了。再透過 Google 搜尋，沒有更多的資料，Delphi 似乎沒有人這樣做，【找不到成員】這問題難道就無解了嗎？

Google 沒有沒關係，Excel_TLB 單元來解答

利用 Excel 執行檔來製作最適合它的 Delphi 元件看來是最終解法，果不其然，答案在這裡：

ExcelApplication 確實有 SmartArtLayouts 成員，接下來就是直接操作它，程式碼直接公開：

VBA 對 OLE 成員非常自由，Item 到底是什麼東西？經查詢的結果是：

微軟連自家軟體的工程師手冊都寫得如此破碎和簡短，也難怪這方面的開發資訊幾近沒有。

原本還要多寫些關於 SmartArt 賦值的內容，無奈再往下追盡是 Access Violation，使用 Excel_TLB 時必定會發生，Stack Overflow 這篇【Delphi - How to create Excel PivotChart】也遇到一模一樣的問題，雖無法找到原因，但改以 OLE 重新刻一次後卻可以解決問題。

2021/08/09

JetBrains 與 StackOverflow 在 2021 年針對全球三萬多名程式開發者的調查

JetBrains 與 StackOverflow 在 2021 年針對全球三萬多名程式開發者的調查。

Delphi 只佔了其中 1%，換算下來也就 300 多人，就計畫遷移數為 0 的狀況下，我猜這 1% 全部都是超過 30 歲的開發者。
而這 1% 裡面中還可以細分：

Desktop = 83%
Mobile = 33%
Web (Back-end) = 61%
Web (Front-end) = 52%

Desktop 使用數最多，表示 Delphi 主力就是在商業開發，Mobile 在這部份僅為加分項目而非主要終端。

Web 比我想像中的還要多，甚至比 Mobile 還要多。

Back-end 和 Front-end 佔比接近，這表示使用 Delphi 若參與 Web，大部份會採用 UniGUI、IntraWeb、DelphiMVCFramework 等中繼開發框架，後端偏多則可能是 DataSnap 也來參了一腳 😁

(你以為我要說 RAD Server 嗎？我偏不！ 😛)

EMBT 在 2012 年開始將重心轉往 Mobile 至今，看得出來 Delphi 開發者依舊未大幅度的往行動裝置遷移，在跨平台的選擇上，Web 還是比 Mobile 多，表示應用程式並不會用到太多 Mobile 硬體周邊，也就能合理猜測 Delphi 主要用在商業應用上。然而 EMBT 已經挹注了大量的資源在 FMX 上，還有辦法再多開戰線到 Web 上嗎？

當然，這 300 人不能代表全球還在使用 Delphi 的開發者，至少我就沒被代表到 😆，但也可能是全球開發者的縮影，可以作為之後移轉到其它平台的參考。

和你分享 ❤

2021/08/03

TMS Web Core 試用心得速記

架構

嚴格來說是 Delphi 的 Web 外掛工具，屬於三層架構裡的客戶端，採用兩種模式：

TMS product bundles

近似 Delphi TDataSet 架構，但有自己的 TConnection (TWebClientConnection)、TClientDataSet (TWebClientDataSet) 和 TDataSource (TWebDataSource)。

TMS product plugin

透過 TMS 自訂的規則把三方 JS 元件，如 TWebJQXGrid 等實作為 Delphi 元件。

它們共同的特色是以客戶端的實作，而非伺服器端，有關伺服器的內容要自行製作，對後端的依賴不再是 Delphi，而是各種 REST JSON API 來源，如 ASP.NET、Python、NodeJS 等。

至於 FireDAC 等 TDataSet 元件則無法使用，TWC 完全和 Delphi 資料庫元件脫勾。

連線基礎

TMS Web Core (TWC) 元件在手冊上以存取 JSON API 為主，XML 倒是沒看到，若是使用 TWebJQXGrid 等三方 JS 元件則還需查來源手冊才會知道。

但 TWebJQXGrid 範例在資料的存取上用的是 CSV，頓時有讓我歪腰到 😆

優點

純客戶端呈現，操作效能會比 IntraWeb、UniGUI 等框架還要好。
Delphi IDE 的可視化編輯器在編排應用程式 UI 上很好用。
可以把各種三方 JS 元件以 TWC 重新實作在 Delphi 上使用，不再受限於 TWC 元件數量。(這點超讚！)

缺點

習慣 Delphi 資料庫元件的開發者需要轉換開發思維；可能要把 TWC 視為 Indy 之類的網路程式開發會比較容易上手。
若用到三方 JS 元件，仍需要學習相關 JS 知識，多了一道轉換工法。

總結

對依賴 Delphi 的開發者來說，投資 JS 的目的只是為了方便開發 Web 前期的磨刀工作，在進入開發期時，則可以完全發揮 Delphi 的優勢，至於 PascalToJS 的繁瑣工作？ TWC 早就為你搞定這一切！

和你分享 😉

大匠之風

網頁