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 的開發者,至少我就沒被代表到 😆,但也可能是全球開發者的縮影,可以作為之後移轉到其它平台的參考。

和你分享 ❤

SEE ALSO

Delphi Data in JetBrains Developers Survey

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 早就為你搞定這一切!


和你分享 😉


See also