2015年12月28日 星期一

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

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

2015年12月26日 星期六

Delphi的OnGetText

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

簡介OnGetText

2015年12月10日 星期四

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
希望大家可以善加利用,解決手邊的程式問題。

2015年11月27日 星期五

數碼的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技術

2015年11月21日 星期六

DELPHI做EXCEL的加總

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

EXCEL的跳行加總

2015年11月14日 星期六

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專注做它要做的工作。

2015年11月5日 星期四

Delphi和其他應用程式的溝通

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

Delphi如何在WORD文件產生表格

Delphi如何產生EXCEL文件

2015年10月30日 星期五

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;

提供給大家做參考

2015年10月23日 星期五

DELPHI又易主了

IDERA 合併 Embarcadero

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

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

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

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


 

2015年10月6日 星期二

Delphi的Post和ApplyUpdate

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

2015年9月21日 星期一

XE10發表會感想

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

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

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

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

2015年9月14日 星期一

響應式網頁設計

因為Google的大力推動,響應式網頁設計(Responsive Web Design)最近非常熱。為了在Google的SEO能提升排名,公司的業務對於這項技術是大力的推動。於是公司的工具網站就被列為改善重點,成為筆者的首要工作之一。
經過三個星期的努力,加上不知如何計算的時間投入,終於做出了一個自己可以接受,別人不知道怎麼想的響應式網頁。
如果你有興趣,可以用手機和PC分別上一下網站  http://tools.hotzsoft.com/ 比較一下二者的不同。
比較好玩的是,為了能如期完成這個工作,筆者用Delphi後端程式來產生前端的響應式HTML網頁。因為程式規則只要訂好,只要測試好一個HTML,其他的HTML網頁就不用逐一測試了,這也是程式的好處。

2015年8月27日 星期四

Delphi Create Form

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

2015年8月20日 星期四

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

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

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

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

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

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

練功是永無止境的。

2015年8月10日 星期一

關帳討論

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

資料關帳

2015年7月30日 星期四

多層式架構的更新

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,很少是更新的錯誤。

2015年7月20日 星期一

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

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

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

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

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

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

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

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

2015年7月14日 星期二

Flow,再討論一下Flow

Flow這個幾年前電腦公司大力宣傳的口號,日前正用另一種方式在企業界發聲--線上簽核。
筆者覺得線上簽核對資訊人員而言是一個大工程。線上的保密、資料的傳送,加上IOS和android不同平台的程式要寫,工程真的很浩大。
不過線上簽核對企業的幫助是不是很大?用小小的螢幕要簽核文件真的方便嗎?
工作流程和待辦事項 這篇文章大家可以參考看看。雖然有提到一些Flow的做法和應用,不過筆者覺得,目的是什麼?它有沒有被達成,是比較重要的。技術只是達成目的的手段。

2015年7月9日 星期四

WEB前端列印

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

2015年7月1日 星期三

DataAware簡易說明

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

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

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


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

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

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

2015年6月17日 星期三

Delphi XE8安裝後沒有Android SDK

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

2015年6月16日 星期二

建立GCM API key

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


1建立專案

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


2015年5月29日 星期五

Delphi技術探討

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

2015年5月27日 星期三

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

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

2015年5月26日 星期二

DELPHI程式人員在那裡

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

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

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

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

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

2015年5月25日 星期一

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

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


2015年5月15日 星期五

DELPHI上WEB辛苦談

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

1.      Delphi本身不能直接橋接IIS,只能使用ISAPI,但這技術似乎過時。
2.      DelphiNative語言,無記憶體自動回收架構。
3.      DelphiNative語言,要Compile之後才能分發。

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

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

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

2015年5月8日 星期五

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月7日 星期四

2015年5月DELPHI XE8發表會感想

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

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

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

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

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

2015年4月6日 星期一

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,特別是沒有複製成本的程式業。希望投入這個程式不歸路的人員都能有自己的思路和看法,讓程式世界多彩多姿。

2015年3月27日 星期五

Delphi的引用問題

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

2015年3月18日 星期三

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

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

2015年3月7日 星期六

Delphi近來排名上升快速

剛剛去看了一下2015年2月的 TIOBE的程式語言排行榜 ,沒想到Delphi的上升速度挺快的,從一月的20名一下上升到11名(如下圖,也可參考上述網站)
感覺真的不錯,比起前幾年Delphi被Borland賣掉,沒有未來的情況,現在真的覺得當初沒有放棄Delphi是正確的選擇。
TIOBE網站中還提到JavaScript是2014年度程式榮譽榜的第一名,我想是因為HTML5的發佈,大大提高了JavaScript的網頁影響力有關吧。
看來用JavaScript來做Web系統,和以前用Delphi開發的資料庫系統做連接,交互完成個別善常的領域是不錯的選擇。特別Delphi在APP的應用上也大獲好評,我想以後應該會有更多人學Delphi,以後找Delphi同好應該比現在更容易吧。

2015年2月27日 星期五

用Delphi發email

最近在做會員管理程式,因為覺得不能用手動方式給會員寄Email,不然量大時是會累死人的。所以決定寫一個小程式來發Email。也許很多人都已經用Indy做過類似的軟體,不過筆者在做時,發現如果給的編碼不正確,收到的Email會出現亂碼,所以把筆者寫的小程式放上來,給Delphi的使用者做Email程式時的寫作參考。
程式說明如下

procedure SendEmail(E_address,UserName:String); // E_address是Email地址,UserName是會員姓名
var
  SMTP : TIdSMTP;
  SMSG : TIdMessage;
  ContText : TStrings;
begin
  // 首先建立一下Indy元件
  SMSG := TIdMessage.Create(nil);
  SMTP := TIdSMTP.Create(nil);

  // ContText 是郵件的內容
  ContText := TStringList.Create;
  ContText.Add('親愛的 '+UserName+ 會員你好:');
  ContText.Add('');
  // 在這邊把想要告訴會員的事寫上去
  ContText.Add('');
  ContText.Add('祝 萬事如意,新年快樂');
  try
    // 以下的xxx請依你的郵件伺服器做設定
    SMSG.Recipients.EMailAddresses := E_address;
    SMSG.ReplyTo.EMailAddresses := E_address;
    SMSG.From.Name := 'xxx.com'; // 寄件人
    SMSG.From.Address := 'xxx.com'; // 寄件人Email
    SMSG.Body.Text:= ContText.Text;
    SMSG.Subject := 'xxxx'; // Email主旨
    SMSG.Encoding := meMIME;
    SMSG.CharSet := 'UTF-8';
    SMSG.ContentType := 'text';
    SMSG.ContentTransferEncoding := '8bit';
    SMSG.AttachmentEncoding := 'MIME';
    SMTP.Host:='xxx'; //郵件主機
    SMTP.Port :=xx; // SMTP的 port
    SMTP.Username := 'xxx'; // 如果你的郵件伺服器要登入帳號才能寄的話,記得要設登入名稱和密碼
    SMTP.Password := 'xxx';
    try
      SMTP.Connect;
      SMTP.Send(SMSG);
    finally
      SMTP.Disconnect;
    end;
  finally
    SMTP.Free;
    SMSG.Free;
    ContText.Free;
  end;
end;

這樣就完成了,試寄的結果還不錯,不過實測時,在
    SMSG.Encoding := meMIME;
    SMSG.CharSet := 'UTF-8';
    SMSG.ContentType := 'text';
    SMSG.ContentTransferEncoding := '8bit';
    SMSG.AttachmentEncoding := 'MIME';
調整時,花了不少時間,因為收信出現亂碼,修改程式再寄,等收EMAIL...如此重覆蠻花時間等待。所以提供給各位讀者做參考。

2015年2月6日 星期五

用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;

2015年1月19日 星期一

規格乎?程式乎?

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

2015年1月5日 星期一

Delphi可以上WEB嗎?

提供一篇還不錯的文章 DELPHI的WEB解決方案 ,在目前大家都熱衷於APP的時候,還有人做Delphi 的WEB解決方案。
大家有空看一下吧,可以讓大家更瞭解在Delphi領域的程式人員在思考什麼,用Delphi開發了那些應用程式。