Excel是許多從事行政人員必用且愛用的工具之一，所以在程式開發上最常遇到的就是客戶拿產品來和Excel做比較。
這能比嗎！(怒吼)
忠孝不能兩全的情況下，拿Excel檔案進行匯入似乎是很常見的折衷方案。
Delphi號稱VB Killer，操作個Excel自然是基本款，來看看Delphi準備了哪些方案？
 |
| Microsoft Office 2000/XP Sample Automation Server Wrapper Components |
Microsoft Office 2000/XP Sample Automation Server Wrapper Components
Delphi很貼心的提供Office元件，自Delphi 7~10.3以來，也就這麼兩套。(2020.03.19更新：XE5之後有單獨提供 2010 套件，但只要 Office 更新也是會有相容性問題。延伸閱讀：Delphi XE5 Office 2013 组件更新)
Office 至目前為止已經2019了，許多使用者都開始使用XLSX新格式，這個元件很早就出現相容性不足的問題。
另一個類似元件的做法是使用Import ActiveX Control，匯入新版Excel ActiveX控制項，實務上還蠻類似元件的操作方式，只是問題在Excel升級後仍有可能會有相容性問題產生。
3rd party
三方元件最好的地方在於使用者電腦並不需要安裝Excel即可進行XLS檔案操作，速度和品質都非常好，我用過的有：NikaSoft NativeExcel
但NativeExcel現在已經沒有維護，對XLSX相容性問題也開始浮現。
無奈之餘，還是只能忍痛放棄它。
XLSReadWriteII
這套是資深Delphier Jason Wong 愛用的Excel元件，而且仍有維護，據稱其優點和NatvieExcel相同，但設計概念非OLE操作，所以沒有深入了解。
看來看去，似乎只能回歸OLE設計方式才能達到最高相容的可能性。
畢竟穩定比效能更加重要！
使用OLE開發
使用官方元件很像是使用全域變數的概念，如果OLE也這樣設計如何？
var FExcelApp: Variant; function ExcelApp: Variant; function IsExcelInstalled: Boolean; var ClassID: TCLSID; strOLEObject: string; begin strOLEObject := 'Excel.Application'; Result := (CLSIDFromProgID(PWideChar(WideString(strOLEObject)), ClassID) = S_OK); end; begin if IsExcelInstalled then begin if VarIsEmpty(FExcelApp) then FExcelApp := CreateOleObject('Excel.Application'); Result := FExcelApp; end else WinMsgBox.WinError('Not found Excel, call EdenWu, please.'); end; procedure CloseExcelApp; begin if not VarIsEmpty(FExcelApp) then begin FExcelApp.ActiveWorkBook.Saved:= 1; FExcelApp.DisplayAlerts:= 0; FExcelApp.ActiveWorkBook.Close(SaveChanges:=0); FExcelApp.Quit; VarClear(FExcelApp); FExcelApp:=Unassigned; end; end; initialization //FExcelApp := unassinged; // this should not be necessary finalization CloseExcelApp;
把Excel Application視為全域變數，隨時要使用Excel Application都沒問題，非常方便。
開始要寫一些關於Worksheet相關的處理了。咦？
好像還不錯，但不夠OOP，還要更多的OOP
寫著寫著，全域變數和全域函式跑來跑去，程式碼看起來就不夠簡潔了，如果使用OOP設計方式會不會更好呢？自己刻好像不錯，只是有個臨摹的對象更好，來看看有沒有好範本可以參考。
這樣的程式碼要自己來寫到底要花多少時間呢？
如果站在巨人的肩膀上會不會省下更多時間做更重要的事呢？
一邊使用SimpleExcel的同時，一邊思考著。
-全文完-
