Delphi XE10 Seattle開發iOS App閃退...

最近遇到一個哭笑不得的問題，空白的App在虛擬機上很正常，但是發佈到實體手機上就馬上閃退。搞了半天終於發現解法已經問題的根本原因，簡單說就是SDK不匹配，把SDK升級就一切正常啦。

Delphi的OnGetText

Delphi中TField的OnGetText事件是比較少用到的一個事件，不過筆者最近因為客戶專案而有一個使用這個事件的範例。提供給大家做參考

簡介OnGetText

Delphi轉Excel的相關資料

自從寫了Delphi轉Excel的應用文章後，客戶也開始問一些轉Excel的相關問題，例如如何在Excel中做Copy、Paste。
在Delphi的指令很簡單
  Excel.ActiveSheet.Range['A1:C2'].Copy;
  Excel.ActiveSheet.Range['B6'].PasteSpecial;
就這二行。
不過筆者發現了一篇好文，它佛心來著，整理了Delphi轉Excel的相關指令，在此提供給大家參考  http://delphi.ktop.com.tw/board.php?cid=30&fid=71&tid=88181
希望大家可以善加利用，解決手邊的程式問題。

數碼的Shadow技術

近來Delphi的活動不少，廖啟甫先進設計了APP在2015-11-25 行動開發成功案例分享研討會上做了發表，筆者覺得很不錯，在這邊給他推一下。有興趣的朋友可以連結以下的網址
YouTube：
https://www.youtube.com/watch?v=J03O9fwq23Q

另外也推薦一下廖先生的部落格：

http://nolanliao1965.pixnet.net/blog

http://nolanliao1965.blogspot.tw

本週參加這麼多活動，要寫文章有點時間不夠，前一陣子看到了另一位Delphi先進寫的部落格 大匠之風 覺得他在寫他進入程式設計這領域的文章很好玩，突然覺得好像有系統的介紹一些技術也是一種可行的方式。

最近在寫公司的專刊文章，其中Shadow技術對如何善用別人的Delphi程式碼，算是一種新的技術應用。當然不一定每個人都需要，不過不一定要用我們家的產品才可以善用別人的程式碼。觀念是可以四處用在適合它的地方，只要你瞭解它。

有興趣的朋友可以參考一下

數碼的Shadow技術

DELPHI做EXCEL的加總

我們常會把資料庫的資料匯到EXCEL中，讓使用者可以用EXCEL來做一些額外的資料計算，例如數值的加總。為了使用者方便，通常在資料轉出時，我們也會把公式放上去，例如=SUM(A2..A10)。
筆者的客戶有一種需求，就是將不同的小計的欄位加總到總計，但是因為中間有正常的資料，所以要跳著加，例如=A3+A7+A10。筆者為了這種情形寫了一篇專刊做法，各位Delphi同好如果有興趣可以參考

EXCEL的跳行加總

Delphi的for迴圈很慢嗎?

有Delphi同好提出一個問題，要計算C(39,5)這種階層的計算，並產生出排列組合的結果。這部分用遞迴或用迴圈來做都可以達到目標。他的問題在產生這些資料太慢了。以上述的計算，會產生37萬筆左右的資料，大約要八分鐘，太慢了，如下圖。

筆者覺得這應該有改善的空間，以前在學生時代寫程式交作業時，這種計算大約五分鐘就出來了，怎麼可能經過那麼多年，CPU都改了幾個世代了，這種數值的計算反而會花的時間更多?

於是筆者要了程式看了一下，加了二行程式，結果如下：

時間變成一分多，為什麼?

  Memo1.Visible := False;

  // 開始時間

  stime := now;

...

...遞迴程式

...

  // 結束時間

  etime := now;

  // 顯示計算時間和產生的數量

  Label1.Caption := '時間： '+FloatToStr(Trunc((etime-stime)*24*60*1000+0.5)/1000)+' 分';

  Label2.Caption := '數量： '+IntToStr(Memo1.Lines.Count);

  Memo1.Visible := True;

紅色是筆者加上的程式，主要的目的在計算過程中，不要讓Memo一直做資料的顯示，等到全部的資料做完，再一次顯示。時間就差了八倍。

Delphi的for迴圈其實是很快的，重點是在迴圈讓Delphie專注做它要做的工作。

Delphi和其他應用程式的溝通

WORD和EXCEL是常用的文書和試算表工具。如果有資料要做統計或做成漂亮的文件，通常我們不會重新寫一個試算表程式，而是會把資料轉到WORD或EXCEL中，再讓這些應用程式接手做往後的工作。
筆者最近因為工作上的需求，做了一些WORD和EXCEL資料轉出的程式工作，寫了二篇和轉WORD、EXCEL的相關文章，有興趣的朋友可以參考一下。

Delphi如何在WORD文件產生表格

Delphi如何產生EXCEL文件

WORD文件取代字串

最近要把WORD文件中的年月和一些日期資料給換掉，不過因為要改的WORD文件太多了，就寫了一段Delphi程式來做修改。
程式說明如下：

// SFile 來源的WORD文件路徑，TFile是要存的WORD文件
procedure ChangeDOC(SFile,TFile : string);
var
  WordApp, WordDocu, myRange: variant;
  sStr,rStr : String;
begin
    // 開啟來源的WORD文件
    WordApp := CreateOleObject('Word.Application');
    WordApp.Visible := True;
    WordDocu := WordApp.Documents.Open(SFile);
    myRange := WordDocu.Content;
    try
      // sStr是要被取代的字串，rStr是要取代的內容
      sStr := Edit3.Text;
      rStr := Memo1.Text;
     // 這一行是重點，啟動WORD的取代功能
      myRange.Find.Execute(FindText := sStr, ReplaceWith := rStr, Replace := 2);
    // 存成新的WORD檔
      WordDocu.SaveAs(TFile);
    finally
      WordApp.Quit;
    end;
    ShowMessage('轉WORD完成');
end;

提供給大家做參考

DELPHI又易主了

IDERA 合併 Embarcadero

這應該是DELPHI愛用者最近的震憾彈。以下是引用新總裁對大家說明的電子檔

http://embarcadero.qcomgroup.com.tw/Customer_welcome_letter_Taiwan.pdf

從DELPHI第一次被賣掉，走了一段黑暗時期，大家都很怕回到先前那段新版開發不良的日子。不過也因為第二度賣給Embarcadero公司，解決了UNICODE的問題，進入APP的發展，才又把DELPHI給救了回來。

新的合併案，不知未來會如何，希望對所有DELPHI的愛好者可以有更多的期待。不過筆者是在資料庫寫程式的人員，對我們這種程式人員來說，IDERA可以提供在這方面更好的支援也說不定。下一版的DELPHI，任重道遠，希望可以給DELPHI愛好者一個新的感受。


　

Delphi的Post和ApplyUpdate

參加DELPHI XE10的發表會後，就一直在忙公司的工作，沒時間上來寫文章。這期間看到了許多Delphi同好在其他論壇討論XE10的APP問題，看樣子XE10這次在APP的支援上，還是有不少狀況。
最近碰上了一位新進的DELPHI同好，他說他老是無法把資料存起來，幫忙Debug才發現是他Post和ApplyUpdate沒有弄懂。所以上來說明一下這二者的區分。
一般Post是把資料存到我們的記憶體，表示我們的資料更改完成，但是並沒有存回後端真正的資料庫，等到我們下ApplyUpdate時才把資料存回後端的資料庫。那為什麼要分這二個動作呢?
因為在修改資料時，不一定只改一筆Record，例如修改明細資料時，通常我們會修改很多筆才一起存回後端，那修改一筆時，如果要檢查資料，這時就需要在Post檢查資料是否正確了，所以Post是檢查一筆資料的好時機。
那Applyupdate存回資料庫是很多筆資料的異動，這時就適合做整體的檢查，例如明細資料的金額是不是和上方的總金額相同等。如果沒有例外，就真的更新資料庫了。
剛入門的Delphi人員常會覺得這二個指令很麻煩，是不是可以合在一起。可是用久了，就會知道這種方式對實務解決問題有很大的幫助。
在此提供新進人員做參考。

XE10發表會感想

上星期同事Download XE10回來試玩，系統需求居然要60G，這也太大了。所以在參加這次的XE10發表會，心中就覺得應該有很多改變，應該有很多新功能。

不過聽完李維和張子仁二位大師的報告後，覺得X E10並沒有加入太多的新功能。這並不是說二位大師說的內容不夠精彩；事實上這次研討會的內容非常的多，時間感覺也很長，而且過程好像在趕進度，就怕會談不完。那為什麼會覺得沒有太多新功能。因為我覺得XE10在完善先前做的功能。以前XE8有加入3D動畫製作、虛擬實境、IOT等新的應用技術，這次也用了許多的新技術，但是都是在強化使用者的操作感受，例如Compiler速度加快，IDE介面強化等。

這也許是個好消息，做過程式設計師的人都知道，如果要在相同的時間內完成多樣的程式需求，BUG就會很多，常有測試不完整的情形。如果不用對新功能做太多的支援，那就有更多的時間來對先前有BUG或不方便的地方做改善。而XE10給我的感覺就是這樣。

Delphi在XE5之後，每次推出新版本，為了配合要完成Android或iOS的版本更新，做了很多的配合動作，往往Bug就很多，通常都要到Update 1才會穩定。希望這次XE10能夠讓使用者第一次上手就覺得有品質。

響應式網頁設計

因為Google的大力推動，響應式網頁設計(Responsive Web Design)最近非常熱。為了在Google的SEO能提升排名，公司的業務對於這項技術是大力的推動。於是公司的工具網站就被列為改善重點，成為筆者的首要工作之一。

經過三個星期的努力，加上不知如何計算的時間投入，終於做出了一個自己可以接受，別人不知道怎麼想的響應式網頁。

如果你有興趣，可以用手機和PC分別上一下網站  http://tools.hotzsoft.com/ 比較一下二者的不同。

比較好玩的是，為了能如期完成這個工作，筆者用Delphi後端程式來產生前端的響應式HTML網頁。因為程式規則只要訂好，只要測試好一個HTML，其他的HTML網頁就不用逐一測試了，這也是程式的好處。

Delphi Create Form

無意間看到 K TOP 一篇 form create form 再 create form 正確寫法? 的文章，原來以前是這樣做的。剛好最近有客戶問到這個問題，於是就寫了一些作法給Delphi新人做參考。(有時覺得目前Delphi的新進人員蠻可憐的，可以參考的資料不是很多，不像以前Delphi全盛時期，到書店滿滿的一整櫃，可以隨便挑適合自己程度的書看)。

如果有興趣的朋友，就參考看看吧 開啟另一個Form 。

上乘讀者只看想法，中乘讀者想看作法，下乘讀者老是想看一堆程式碼。

最近因緣際會，重讀DELPHI元老級高手 陳寬達 先生的古灰級書籍， Delphi 深度歷險 。其中有一段話筆者覺得說的非常好。對於這句話，引用如下：

對於書籍的範例程式，我是這樣認為的：上乘讀者只看想法，中乘讀者想看作法，下乘讀者老是想看一堆程式碼。

想法要變成作法，需要對電腦運作的方式有深入的瞭解，才能產生要運作的程式邏輯。作法變程式碼，則是對所選的語言的瞭解。這邊應該就是對DELPHI的瞭解。

筆者的工作，一直都在資料庫這個領域。所以久了也就非常習慣用以前的解決方式來解決眼前的問題，反正程式用COPY的最快。累積的經驗不就是為了能快速的解決問題嗎?程式為什麼要有LIBERY，就是要縮短解決問題的時間，不是嗎?

不過這種只做COPY的行為好像比下乘讀者做法還差。程式的世界一直在改變，也許筆者在接新案的同時，也要回想一下以前的解決方式是不是有更好的解決方式。

練功是永無止境的。

關帳討論

筆者最近為了客戶的關帳，寫了一篇有關企業關帳作業的一些小做法，有興趣的朋友可以參考一下。

資料關帳

多層式架構的更新

DELPHI的最大討論區(就筆者的感覺)，應該就是K TOP了，近日看了一篇文章  面對快速持續改善的多層架構系統要如何規劃版本更新架構呢？  覺得很有趣，於是就做了一些回應，想不到一些淺見還得到大家的討論，所以說明一下本人的程式更新方式。還請大家多多指教。

首先，我們會把程式做一些分類，然後做一些存放程式位置的規定。

接下來，會有一個共同的檔案管理區，這個區域存放大家寫的程式，當個人要修改程式時，就要從這個區域CHECK OUT程式，這時程式就得屬CHECK OUT的人了，除非該名程式人員把程式更新CHECK IN，否則是不可以更動的。這樣才不會有程式互改的情形發生。

因為DELPHI這種語言的特性，基本上就是為程式人員設計的，所以大家寫的程式都是在自己的電腦上做測試。在自己Local的開發環境上開發程式是有道理的，因為這時你負責的程式你最大，你可以依自己的方式來解決問題(當然還是要遵守一下大家的規定，例如預設值的EVENT位置、引用適當的公共程式，而不要自己寫一套解決相似問題的程式等)，這樣程式的開發效率最快，DEBUG也很容易。

程式測試OK後，就會把程式上傳到共同的檔案管理區，這時個人的程式就告一段落了。

程式的更新分為AP端和Client端。如果狀況很緊急，程式馬上要用(例如不更新程式就沒辦法發薪水)，那就用平台工具更新資料庫，並把AP程式和Client放上主機。然後請使用者從新進入系統，當使用者使用到更改的功能時，就會自動下載Client端程式，然後用新的程式運作。

至於不緊急的程式，可以等大家都下線時做更新，因為有一堆人做修改，其實也很難知道每一個人改了什麼。但是可以確定，就是在共同管理區的程式是可以正確WORK的。那就用平台工具，把資料庫CREATE一次(平台工具會先比對TABLE，有修改的才做修改)，再把程式全部重BUILD，COPY到主機。這樣更新的工作就完成了。主要是資料庫和AP程式會同步更新，Client端是使用者有用到程式，才比對做更新。

沒有特別好，也很平實，不過會有問題通常都是程式人員程式有BUG，很少是更新的錯誤。

程式人員最重要的工作-思考並下決定

最近因為工作上的關係，在公司寫了一篇專題文章  待辦事項vs警告和提醒，如果有興趣的朋友，可以參考一下。

我們在完成系統時，往往花了很多的時間去確認程式的完整度和測試程式是否有BUG。在花了這麼多的時間之後，如果要加上待辦事項，或是異常的警告；這時就會面臨一個抉擇，是要修改原來的後端過帳程式呢?還是獨立用另外一組程式來做新功能?

如果只是一二個程式的修改，一般都會選前者；不過如果是會一直追加的功能呢?例如異常的提醒就是會一直加的功能。首先會是一二個異常的提醒，例如庫存不足時提醒。接下來USER就會說那庫存都可以提醒了，那支票到期是不是可以提醒?上班忘刷卡是不是可以提醒?主管簽核超過時間可否提醒?....然後你就會發現異常的提醒功能可能不會比ERP系統小。

這時如果你選擇的是前者，我想這時程式應該已經複雜到很難改變的地步了，要再找人訓練應該有困難了。如果你選的是後者，那至少系統比較好理解，可以分派給不同的人，擴充性是比較好的。

這樣講好像很簡單，問題是一開始都只是一二個小問題，怎會知道後面會變化這麼大?都改了這樣一大堆程式了，那是要回去重頭選擇第二種方式，把程式改回去，還是就這樣用第二種方式，程式繼續給他複雜下去?

判斷是程式人員最重要的工作，選對上天堂，選錯下地獄。千萬不要聽信USER給你的訊息，你一定要自己加以判斷，後續的變化和追加是不是會很多?因為那都會變成你的工作量。我相信你想過，做了決定，不論是對是錯，你心理都會舒服一些，因為那是你選的。

選錯了沒關係，在系統沒變複雜前，修正過來就行了。重要的是你想過，知道你為什麼做了這樣的選擇。這樣經驗多了，你的選擇對的機率會提高很多。

Flow，再討論一下Flow

Flow這個幾年前電腦公司大力宣傳的口號，日前正用另一種方式在企業界發聲--線上簽核。

筆者覺得線上簽核對資訊人員而言是一個大工程。線上的保密、資料的傳送，加上IOS和android不同平台的程式要寫，工程真的很浩大。

不過線上簽核對企業的幫助是不是很大?用小小的螢幕要簽核文件真的方便嗎?

工作流程和待辦事項 這篇文章大家可以參考看看。雖然有提到一些Flow的做法和應用，不過筆者覺得，目的是什麼?它有沒有被達成，是比較重要的。技術只是達成目的的手段。

WEB前端列印

最近筆者和客戶見面，談到WEB的一些解決方案。發現有些工程師覺得Browser就是在WINDOWS上執行的程式，所以列印方式應該和在WIN FORM上的列印方式應該很接近。其實Browser為了安全性和本身作業的獨立性，不會和作業系統做很緊密的結合。
因為Browser有這樣的特性，所以要做類似ERP報表套印的程式，就變的比較麻煩，筆者寫了一篇有關 WEB列印 的文章，大家如果有興趣，可以連進去看看，參考一下。
對WEB老手來說，這應該是基本知識了，如果你剛進入WEB寫HTML，希望這篇文章對你有幫助。

DataAware簡易說明

最近一直在忙做產品的影片，其中有做到在WEB上的DataAware。如果對DataAware案例有興趣的朋友，可以參考一下 DataAware的簡介說明 這個影片。

既然都提到DataAware了，就來說明一下它的應用和好處吧。我們在做程式設計時，畫面顯示的資料和資料庫儲存的資料，基本上是連動的，一般而言，以下圖為例

左方的GRID如果筆數更改，右方EDIT的對應欄位也要跟著改變。同樣的如果右方EDIT修改內容，左方的GRID內容也要跟著改變。因為是他們都是同一筆資料。


現在問題來了，每個對應的欄位都要寫程式去改變其他元件(GRID、EDIT、CHECKBOX等)，工程是不是太大了。如果資料TABLE加一個欄位，是不是程式又要加一堆互動的程式?

DataAware就是為了解決這個問題。它的原理是以DataSet為中心，所有和DataSet有關的元件，只要有值變更，就會通知DataSet，然後DataSet再通知相關元件做資料的更新，達成資料的一致性。

有了DataAware和資料感知元件，程式人員就不用花心力在資料的同步上，可以減少大量的程式負擔。

Delphi XE8安裝後沒有Android SDK

Embarcadero Delphi XE8 安裝時會讓使用者選取是否要安裝Android SDK及NDK，但是不知是否因為我是裝在VirtualBox中的關係，安裝後在Tools > Options 中的 SDK manager會有錯誤，顯示找不到檔案。該怎麼辦呢?

安裝後發現有3個錯誤警告

建立GCM API key

在建立GCM專案時需要API Key，網路上找到的範例是舊版的介面，因此重新整理了新版介面的操作過程供大家參考。

1建立專案

進入https://console.developers.google.com，建立有Cloud Message功能的專案。

Delphi技術探討

近來看了二篇Delphi的技術文章，Delphi 在Script 不缺席 和 Delphi 寫DLL需注意的事項 這二篇文章，第一篇提供了一些Delphi的支援訊息，第二篇則提供了作者的實作經驗。有興趣的人可以參考一下。
筆者一般寫的都是BPL，DLL比較少做，不過以前曾經用DELPHI5寫過MRP的DLL展算程式，看到DLL不能用ADO Connection，心中覺得納悶，那我是如何解決?於是回頭去看了一下以前寫的程式，發現我是用BDE做的。這下尷尬了，BDE已經進入末期了，不知客戶還有沒有在用這個程式是不是要重新改寫。
也許對DLL也要再花點時間研究、測試了。

[分享]保哥的30天精通Git版本控管

Git是個大名鼎鼎的分散式版本控管工具，在iT邦幫忙看到保哥分享他對Git的知識，覺得很有用想和大家分享

DELPHI程式人員在那裡

在參加XE8發表會時，現場有人提出要去那邊找DELPHI工程師。我在客戶那邊也常被問到可否介紹DELPHI工程師。因緣際會有機會到中部一家科技大學和一位教DELPHI的老師見面，談一些合作的可能性。也因此有機會瞭解一下DELPHI新鮮人的近況。

第一個消息是，第一名DELPHI優秀的三年級同學已經被訂走了。所以如果要找DELPHI不錯的新鮮人要一年前就預定了，看樣子要挖角的成本應該也不低。該名學生專攻目前最HOT的APP通訊推播，看他問老師的問題，在實作上應該有一定涉入程度才是。
我們需要的DELPHI新鮮人是要做新的程式應用，還是接手我們已開發維護的系統?會不會就算有DELPHI新人加入，他們也要在新領域發揮，而不是在我們的ERP資料庫打轉?在資訊業，應該不像公家機關或是傳統行業要靠經驗取勝。資訊的範圍太大了，不同的領域都可以養活一票人，新人不一定要承接我們的工作往上爬。

第二個消息是DELPHI程式設計師的養成率是10%。以一年一百個學生來算，可用的DELPHI學生只有10個，真正進入到DELPHI發展的應該不到10個，這個數字應該無法滿足市場的人才需求吧。所以需要DELPHI程式人員的主管們，如果你想讓自己的新人訓練輕鬆一點，有空到學校拉一下人吧，只靠104恐怕只能怨嘆難找人了。

優秀的人總是少數。如果沒有能力教優秀的人才，對他們不但是一種傷害，也留不住這些優秀的程式人員。在學校和老師們談這些學生，和學生談一下他們對程式世界的看法、他們手上目前程式工作的現況，有一個深刻的感覺。程式能力的高下決定你能吸引什麼樣的人。優秀的程式人員對解決程式問題的沈迷，就像鯊魚見血一樣。能用你在程式上的知識去解決他的問題，才能吸引他進入你的公司。

技術是一切的根本，大家努力吧。

[分享] Delphi 的 TColor 與常見 Hex 16進位色碼轉換

在網頁上總是有許多漂亮的顏色，我們也可以用簡單的小程式把它轉換成TColor
讓我們的程式不會總是預設的clBlack，clRed，clBlue...
以下是程式碼，原著來自Zarko Gajic

DELPHI上WEB辛苦談

當初要把Delphi上WEB是一個【選項】，不是個【必然】。可以選擇C# 或是 Java。幾經考慮之後，還是利用Delphi上WEB，但幾個問題橫在眼前：

1.      Delphi本身不能直接橋接IIS，只能使用ISAPI，但這技術似乎過時。

2.      Delphi是Native語言，無記憶體自動回收架構。

3.      Delphi是Native語言，要Compile之後才能分發。

左思右想之後，只有取巧利用C#當IIS與Delphi橋接口，將來自Browser需求利用C#轉呼叫由Delphi 做成的COM SERVER。C#負責Session 管理，Delphi提供服務。如此一來，就輕易解決上WEB的架構。

【無記憶體自動回收架構】這問題在傳統上是相當嚴重，因為Server 需長期運行，如果有記憶體遺漏，很快就會造成Server死當。後來，幾經折騰COM SERVER改成Single Instance之後，這問題就不嚴重了。因為，每個使用者都是獨立，反而系統更穩定。

【要Compile之後才能分發】這問題會帶來版本及分發安全的問題，不過，後來實作一個系統分發之後，這問題變成小問題。

Delphi COM 的再認識

在發展delphi 上WEB的過程，由於整個專案是利用DOT NET 呼叫Delphi 的COM Server。因此，很自然就研究起Delphi 的COM架構。不過，也遭遇了幾個困難：
1. COM+ 跟 COM的註冊是截然不同。
2. COM的 TYPE LIBRARY 如何繼承。
3. COM的 Instance 的選擇。

   由於透過IIS呼叫，一定要是COM+的註冊方式，但Delphi 內建的 COM註冊程式只支援COM，不支援COM+，因此，專案的一開始，單單這問題就搞了快一個月。

   由於希望每個專案能有自己的COM SERVER，最終是一台電腦可獨立運行多個專案，但問題是，每個專案都是由模板專案產生，但TYPE LIBRARY要不同。如此一來必須是繼承，才能達到目標，但第一次摸索delphi 的TYPE LIBRARY繼承要花了一點時間，不過，也因此感受到delphi在這方面支援不錯。

   基於過往的使用經驗，很自然選擇ciMultiInstance(Delphi Create COM 中的一個選項)。 但問題來了，delphi 的MultiInstance 是要自己實作，這問題找了資料之後很快就突破了，真正問題在上線之後。

   再經過一年左右奮戰終將專案完成，懷著戰戰兢兢的心情既期待又怕受傷害的心情，測式上線。剛開始無異狀，因上線人數不多，但人數一多COM SERVER會死當。這下心情跌到谷底。因為，這種Run time 的錯誤特別難抓。想想這問題不僅底層須解決，讓問題更複雜是：客戶買了這產品回去，還會自行加工。那如何避免Server如何死當，不僅底層程式碼必須注意，客戶也要有足夠的知識避免，那這教育訓練成本未免太高了，於是思索如何讓每個Server 都是獨立不會互相干擾，當成是研發的方向，而且就算Coding 不到位也無妨，果然一試之後，COM Server 再也不當，甚至比NET 研發更穩當。

PS: 不過，獨立的COM SERVER研發也帶來別的挑戰。不過，這不是本次文章的主題，故不在此深述。

2015年5月DELPHI XE8發表會感想

昨天去參加捷康XE8發表會，會中李維大師說明了許多XE8的新功能，特別是在IOT(Internet of Things)的部分。XE8為了讓開發者方便作業，除了貼心的加了新元件外。也為設計環境做了許多方便性的改善，讓程式人員可以快速方便的完成程式設計。

在整場會議中，李大師解說了一些DELPHI底層的工作，其實這才是一個開發系統的重點。這些在外面看不到，不起眼的地方，其實就是整個系統運作的關鍵。通常我們都是設一設元件屬性，在事件寫一些程式去做元件的變動和處理。但是這些元件是如何運作的，就比較少人去瞭解了。當元件達不到我們的目標時，我們就會覺得元件功能不足，但是往往是我們沒有瞭解元件，不瞭解這些元件的設計初衷。誤用或是不知如何去善用這些元件來達成我們的目標。

以前學程式設計時，總是學語法，學結構，才開始寫自己的程式。不過昨天上課後，對學程式這件事有了不同的看法。電腦世界的變化太快了，以前可以用幾個語法來解決的程式，現在是要用一大堆的元件才能完成目標。用元件來組合程式是很快，站在別人的程式上架構系統也很省力。但是如何去理解別人設計的元件，反而成為最重要的核心工作了，這些都是要花時間才能打下根基，讓自己的工作更順利。

另外還有一件事應該說一下，以前學程式，不會就問前輩，因為電腦就是處理計算問題，有BUG也好解決。現在元件不但多，而且深入的領域都不同，特別是IOT都有和硬體做溝通，很多程式都和藍芽有關。所以現在學程式，要先GOOGLE一下自己的問題，整理思考，並在DELPHI試過之後，才能提出比較好的問題。對要解題教導你的前輩而言，這也是一種尊重。

急著想解決問題是人的常態，但未經思考的問題，往往只是顯示自己不成熟。

Source Code VS Help

前一陣子有朋友發表了一個有趣的說法，他說程式目前有二種理解方法。一種像.NET，微軟會給你一大堆的文件(Help)，例如MSDN。你要瞭解.NET，就必須看這些文件才知道.NET在做什麼，你可以如何使用.NET來達成你的目標。
另一種是C和PASCAL，基本上不會有什麼Help，但是會附上Source Code，你要瞭解它，就必須從Source Code的執行過程中去體會程式的奧妙，吸收成為你的知識，然後才能使用這種語言。
感覺Delphi就像以前的師父教徒弟，領進門後就看徒弟的天資適不適合吃這行飯了。做的久了，看的程式多了，就可以建立起自己的Coding方式，發展自己的思考邏輯。習慣了，就可以很深人的去應用這些基礎的知識，來解決面臨的問題。
相對的，有Help就可以快速入門，可以大量的產生出簡單的應用，大量的招募人員來大量學習。不過因為程式被包在一個個的DLL中，程式人員只能用HELP來引用這個DLL，但是這個DLL在做什麼?為什麼可以這樣做?確是一個黑箱。一但微軟放棄開發(從以前的Foxpro、VBScript等)。就必須重新學新的，一切重頭開始。

不過筆者心裡想，如果Embarcadero沒有附予Delphi新生命，那PASCAL不是也和FoxPro一樣?要追上APP和HTML的世界，一樣要重新學新語言吧?我覺得語言的發展和延伸性應該被踢除在Source Code和Help的比較之外，任何一種語言如果沒有延續先前語言的精神，在新的應用領域內做開發，對投入的程式人員，都是一種沒有未來的切身之痛。
不過筆者還是喜歡Source code勝過Help(如果一定要二者選其一的話啦，因為在討論時，發表者說給Source code了，那有美國時間再寫Help)。因為Source Code是一種真實的存在，可以瞭解程式為什麼是這樣，而不是照我們的想法走。有了思考，程式人員的價值才會產生出來。現在這個世界，最不需要的就是ME TOO，特別是沒有複製成本的程式業。希望投入這個程式不歸路的人員都能有自己的思路和看法，讓程式世界多彩多姿。

Delphi的引用問題

前一陣子有朋友問到，我給的IncMonth(Date:String;IncValue:integer):String;這個函數和原廠提供的function IncMonth(const DateTime: TDateTime; NumberOfMonths: Integer = 1): TDateTime;相衝突。不知道要如何解決。
其實解決這問題很簡單，要使用Delphi的函數，只要加上引用的來源 SysUtils. IncMonth()就行了。當Delphi的來源取得順序不如我們想的，就加上來源，就可以解決了。

2015Delphi新版本技術研討參加後感想

今天參加 2015 RAD Studio 新版本技術發展方向研討會，聽到了難得一見的李維大師對目前Delphi的發展方向做了說明。
從李維大師的介紹和說明中，可以感覺到Embarcadero這家公司為了物聯網，積極的投入人力在這方面做研發。除了讓程式人員可以在原本的Delphi上開發iOS和Android外，也開始讓一份Source Code可以支援32和64bit版本的作業環境。更好的是，可以在設計時就看到程式在不同Size大小螢幕上的表現，這讓開發者可以節省不少設計時間。
會場中也用XE8做了和Beacon連接的展示，感覺在應用上提供了很好的介面，也很方便做開發，看樣子只要選了XE8，剩下的就是好的創意點子了。
難怪Delphi最近的使用者排名上升的蠻快的，也許五月份XE8正式出版時，可以像先前Delphi3和Delphi5時一樣，在程式設計領域看到一陣旋風。

Delphi近來排名上升快速

剛剛去看了一下2015年2月的 TIOBE的程式語言排行榜 ，沒想到Delphi的上升速度挺快的，從一月的20名一下上升到11名(如下圖，也可參考上述網站)

感覺真的不錯，比起前幾年Delphi被Borland賣掉，沒有未來的情況，現在真的覺得當初沒有放棄Delphi是正確的選擇。

TIOBE網站中還提到JavaScript是2014年度程式榮譽榜的第一名，我想是因為HTML5的發佈，大大提高了JavaScript的網頁影響力有關吧。

看來用JavaScript來做Web系統，和以前用Delphi開發的資料庫系統做連接，交互完成個別善常的領域是不錯的選擇。特別Delphi在APP的應用上也大獲好評，我想以後應該會有更多人學Delphi，以後找Delphi同好應該比現在更容易吧。

用Delphi發email

無法查看此摘要。請 按這裡查看文章。

用DELPHI產生HTML

大家熟悉的HTML一般都是用UTF-8格式來做存檔格式，可是DELPHI所用的TXT FILE卻都是用ANSI格式，所以在存檔和轉換都會有許多問題，那怎麼做比較好呢?
筆者最近因為工作上的關係，常會用HTML做樣板，然後再用DELPHI把檔案讀進來，做一些轉換，再形成新的HTML供BROWSER讀取，就碰上了格式的問題。
最後的解決方式是用TStringList的LoadFromFile來解決這個問題
舉例如下
function RefreshHTM():String;
var
  HTML1,HTML2  :TStrings;
  FG : Boolean;
  i : Integer;
begin
  try
    // 宣告二個TString，HTML1承接HTML樣版，HTML2是做轉換後要顯示的HTML結果
    HTML1 := TStringList.Create;
    HTML2 := TStringList.Create;
    try
      // 取得樣版的HTML
      HTML1 .LoadFromFile('D:\web_root\html\PTL01U05.htm');
      for i :=0 to HTML1.Count-1 do
      begin
        // 逐筆把資料抓入
        Ln := HTML1[i];
        // 這邊做想要更換的作

        // 把更改後的資料加到HTML2中
        HTML2.Add(Ln);
      end;
      Result := HTML2.Text;
    finally
      //把資料傳出後，把TString Free 掉
      HTML1.Free;
      HTML2.Free;
    end;
end;

規格乎?程式乎?

每個程式在設計時，都有它要完成的目標，也都有它要完成工作的前提。程式設計師常會接到使用者來電說，程式跑的結果有問題。我相信程式有BUG在所難免，坊間也有一堆關於如何DEBUG，如何防止BUG發生的方法。不過會不會最大的BUG就是人?
很久以前，看到一篇系統上線的文章，其中提到「樹大必有枯枝，人多必有白痴」，其中的白痴就是在諷刺程式設計者的設計軟體理念很奇怪。不過有時候使用者定義的需求也常令程式設計師瞠目結舌，不知道這設計邏輯是如何跑出來的。
感覺BUG不一定存在電腦中，更常存在人的大腦中。不論是程式人員或是使用人員，通常都有一定的思考方式，而當二人的思考方式放在一起時，就會有溝通不良的問題，如果沒有消除彼此的歧見，BUG就是接下來的產物了。每個人心中的「理所當然」或許就是BUG的源頭吧，也許在DEBUG電腦的BUG前，應該先DEBUG一下自己的想法。
最近常聽到使用者的一堆問題，往往都是使用者沒有先瞭解系統的運作方式，才會有「BUG除不盡，春風吹又生」。在除舊佈新的這段時間，我想也該更新一下自己的思考方式了。也許程式人員的第一要務是讓使用者瞭解程式在做什麼，而不是Coding程式。

Delphi可以上WEB嗎?

提供一篇還不錯的文章 DELPHI的WEB解決方案 ，在目前大家都熱衷於APP的時候，還有人做Delphi 的WEB解決方案。

大家有空看一下吧，可以讓大家更瞭解在Delphi領域的程式人員在思考什麼，用Delphi開發了那些應用程式。