顯示具有 Delphi 標籤的文章。 顯示所有文章
顯示具有 Delphi 標籤的文章。 顯示所有文章

2024/03/11

FastScript 實現多語言設計

 

作者:吳祐賓

 


 

最近我的程式莫名出現了:EOleSysError: 類別未登錄, ProgID: "MSScriptControl.ScriptControl" 的錯誤訊息。一查才知道原來是 Windows 沒有提供 Microsoft Script Control 64 位元版本,但許多程式會用到 JScript。遇到這難題該怎麼處理呢? 

 


 

 

使用外掛 Tablacus Script Control 64

 

外國網友 Gaku 提供了好用的 OCX 套件:Tablacus Script Control 64。現有的程式幾乎不用修改就可以使用。缺點是必須要另外安裝。截取官方範例如下:

 

var SC = new ActiveXObject("ScriptControl");
SC.Language = "JScript";
SC.AddObject("WScript", WScript);
SC.AddCode('function fnx(a,b,c){ WScript.Echo(a + ":" + b + ":" + c) }');
SC.Run("fnx", 1, "data2", "data3");

 

使用直譯式工具 FastScript


FastScript 是 FastReport 公司旗下的直譯式跨語言開發套件,可在不開啟程式編譯器的場合下做簡易的程式開發。使用起來也相當簡單。缺點就是 JScript 語言支援度比微軟老舊的 JScript 版本更為受限。

 

procedure TForm2.Button1Click(Sender: TObject);
var
  LfsResult: Variant;
begin
  fsScript1.Clear;
  fsScript1.Parent := fsGlobalUnit;
  fsScript1.SyntaxType := 'JScript';
  fsScript1.Lines.Text := 'function jMethod(a, b){return a+b}';
  if fsScript1.Compile then
  begin
    LfsResult := fsScript1.CallFunction('jMethod',VarArrayOf([1, 1]));
    ShowMessage(LfsResult);
  end;
end;

 

總結

 

兩種解決方案各有優缺點,使用者可根據自身需求進行選擇:

 

若需要使用現有的程式,且對相容性要求較高,採用 Tablacus Script Control 64 外掛可以很快進入狀況

 

若需要快速開發簡易的 JScript 程式,或對相容性要求不高,則可以使用 FastScript 直譯式工具

 

其他注意事項

    使用 Tablacus Script Control 64 外掛時,需注意其版本與 Windows 系統的版本是否相符。
    使用 FastScript 直譯式工具時,需注意其對 JScript 語言的支持程度。



本文介紹了兩種解決 Windows 64 位元系統下使用 JScript 的方案,希望能對相關使用者有所幫助。

 

 和你分享

 

See also

 


2023/10/06

[CB][Delphi]解決跨國小數點符號不同的程式處理

作者:吳祐賓





多數歐洲國家的數字浮點數,會使用逗號「,」作為小數點基點。

這陣子接獲客戶反應他們開發的軟體遇上 "Invalid floating point operation" 的錯誤

雖然最後並沒有採用程式解法來撫平此問題,只是這解決過程太有趣,一定要和你分享!



2023/05/25

讓 Delphi 11 產出的執行檔相容 Windows XP

作者:吳祐賓

 


 

Delphi XE 下熬了很久,就在 2023 年正式升級 Delphi 11 後,才由原本「修理 IDE 的快樂」轉變為「升級後的快樂」,然而這快樂沒有多久,很快的使用者就傳來災情:

無法執行

依稀記得幾年前的 Delphi 研討會有提到新版 Delphi 產出的執行檔無法在 Windows XP 下執行,想不到在 2023 年的今天,仍然會遇到必須要使用 Windows XP 的場合,2001年10月的產物。

難怪每次購買新版 Delphi 時都能下載過往舊版本,是時候再把 Delphi XE 拿出來把玩了! 

你也是這樣想嗎?太天真了。Delphi 11 已經貼心的在編譯器設定裡加入了【PE Header】選項!

2022/02/17

What is Encryption in Delphi?

 


I remember that when I mentioned that Delphi did not officially have an encryption unit in a discussion with my friends, I always thought it was incredible, because DataSnap has this encryption filter:

TTransportFilterItem.FilterId: PC1 / RSA

Since there is an encryption setting, the encryption method must be hidden somewhere in the Source paths.









It cost me 8 damn nights!



How exactly does DataSnap operate encryption? I muttered to myself as I silently stared at the screen in the dark.

Quest

Find of the DSTCPServerTransport unit, I saw the dependent DBXTransport, and I saw a sensitive word in "uses":

DBXEncryption

As if seeing a glimmer of light, I find the Delphi installation path and opened the mysterious DBXEncryption source code.

It begins with this:

PC1 encryption definitely came from here.

TPC1Cypher is the PC1 encryption class, and my intuition tells me that RSA is maybe TRSACypher.

But there is no trace of it in the DBXEncryption unit, is it a mistake? I try to find possible clues in the source code sea.

DBXOpenSSL

The beginning of the file reads like this :

Sure enough, as I expected, the RSA encryption method is named after [TRSACypher].

PC1 encryption filter provided by DataSnap Server

DataSnap Server provides PC1 encryption filter. At the beginning, everything uses the official default value. There is no problem in operation, but the Key value is fixed, so let's modify it.

After modifying, the operation is also success. After the normal measurement, I try the [what error will pop up if the server and client passwords are different].

The result can still run successfully!

Why does it work with different KEY values on both sides? After being tested, it goes through several units:

  • DBXTransport
  • DBXEncryption

There are Cypher / Decypher encryption and decryption functions in DBXEncryption.TPC1Cypher class. After testing, we know that when each pair of packets is encrypted and passed to the other party, it will also be passed to the other party together with the "KEY", and the other party will use the "KEY" to decrypt the packet, and vice versa Of course.

To put it simply, the packet can be decrypted correctly only when the KEY is used with the [same] algorithm to decrypt the packet.

 

Therefore, it is the key to know the correct algorithm. Although as long as it is a Delphi application, it can be unraveled, but in such a niche as Delphi, it can be regarded as a good encryption method.  😁


See also

2022/02/16

Memory Table Showdown! FdMemTable vs VirtualTable vs ClientDataSet, Part 1: Increase Data

Content

English Version

Recently, I saw people debating in a technical group about which method is better for writing data to a database, and it surprised me that the way a program controls writing to a database can affect the writing results. This piqued my curiosity, so I decided to conduct a test myself to see how much of an impact poorly written code could have on rapid memory table operations.

In Delphi's TDataSet, there are two well-known methods for adding new records:
  1. INSERT
  2. APPEND

What is "INSERT"?

Inserts a new, empty record in the dataset. 

What is "APPEND"?

Adds a new, empty record to the end of the dataset.

Some people say that INSERT is more efficient than APPEND, which is quite surprising. My previous impression was that APPEND was faster, but I don't remember how much faster it was. Now, I will write down the test results to see how much difference there really is between the two methods in terms of performance.

Testing method:

  • Test time: 100,000 records
  • Table structure: 3 fields (Integer, String, String)
  • Record unit: milliseconds

    Example using ClientDataSet

    From the above figure, it can be seen that Insert takes much more time than Append.

    Next is the time required for each ten thousand records:

    As the data amount increases, the time required for Insert also increases. When it reaches 90,000 to 100,000 records, it takes 797 ms.

    The result is obvious, Append is better.

    But this result is really boring!

    ClientDataSet is a type of Memory Table. If we compare it with other Memory Tables...

    Speaking of Memory Tables, there are many options to choose from. Here are the competitors for this test:

    • FireDAC -- TFdMemTable
    • Devart -- TVirtualTable
    • DataSnap -- TClientDataSet

    FireDAC -- TFdMemTable


    Similar to ClientDataSet, FdMemTable also spends more time on Insert than on Append.

    Devart -- VirtualTable





    In VirtualTable, we can also see that Insert takes longer than Append. But please note that the total difference of 32 ms is not very noticeable in terms of user experience. This means that users of VirtualTable do not need to pay too much attention to program details 😋.

    Three-way showdown

    The contestants have all completed their individual events, and now it's time for the showdown:




    Summary

    Although memory operations are very fast, careless handling can still lead to performance tragedies.

    In cases of massive data insertion, using the Append method is undoubtedly the best practice.

    The above conclusion is an exception for VirtualTable. 😁

    The performance difference between Insert and Append is the biggest in ClientDataSet. Developers who use it should pay attention to optimizing their code.

    FdMemTable, as the successor of ClientDataSet, is not good enough for performance-obsessed developers yet, but it still has room for improvement.

    "DBNavigator.Insert" and "TDataSetInsert" in ActionList are both "Insert" actions and neither of them has "Append". If needed, manual modification is required. Fortunately, in the case of "end-users", it will not have too much impact.


    Next time someone tells me that Insert has better performance than Append, I'll kick them out! 😊


    中文版本 (2017/08/14)

    最近在技術群組裡看到有人在爭論寫入資料庫的方式孰優孰劣,看到程式控制寫入資料庫的方法,居然也會影響寫入結果;這引發了我的好奇心,就自己來測試看看在飛快的記憶體表格操作,如果程式寫得不好,會有多大的影響。

    Delphi 的 TDataSet 在新增上有兩個著名的操作方法:

    • INSERT
    • APPEND

    What is "INSERT"?

    Inserts a new, empty record in the dataset. 

    What is "APPEND"?

    Adds a new, empty record to the end of the dataset.

    這兩者的比較,居然有人說 INSERT 比 APPEND 的效能要來得好,真是意外,我以前的印象中,記得是 APPEND 要來得快,但已經不記得快多少,現在就來把測試結果寫下來,看這兩者到底的效能差別到底有多大。

    測試方式:

    • Test time:100000 Record
    • Table Structure: Integer, String, String; 3 Fields
    • Record unit: ms

    以 ClientDataSet 為例:

    由上圖可知, Insert 遠比 Append 要花更多的時間。

    接著是每累加一萬筆時所需的時間:


    隨著資料量越多,Insert 所需的時間就越長,當九萬至十萬筆時,就需要花上 797 ms 的時間。

    結果很明顯,Append 勝出。






































    但這樣結果實在是太無趣了!

    ClientDataSet是一種 Memory Table,如果把其它的 Memory Table 一起抓來比較的話……

    說到 Memory Table 的選擇非常多,以下是本次參戰的選手:

    • FireDAC -- TFdMemTable
    • Devart -- TVirtualTable
    • DataSnap -- TClientDataSet

    FireDAC -- TFdMemTable



    就像 ClientDataSet 一樣,FdMemTable 在 Insert 明顯比 Append 花更多的時間。

    Devart -- VirtualTable






    VirtualTable 也可以看到 Insert 也要比 Append 要久。

    但請注意!32 ms 的總差距在體感上其實是差不多的!

    *意謂著使用 VirtualTable 的人可以不用太在意程式細節 (笑)


    大亂鬥

    選手們都已經完成個人賽事,接下來就要登台對決:




    總結

    僅管記憶體非常快,但操作不慎仍有可能造成效能悲劇。

    在大量新增的場合,使用 Append 的方式絕對是最佳作法。

    以上總結在 VirtualTable 是個例外。(笑)

    ClientDataSet 在 Insert / Append 效能落差最大,有在使用它的人要注意手上的程式碼優化工作。

    FdMemTable 作為未來 ClientDataSet 的接班人,對效能偏執狂的開發者來說還不夠好,請再繼續加油。

    「DBNavigator.Insert」和 ActionList 裡的「TDataSetInsert」兩者都是【Insert】行為,而且它們都沒有【Append】,需要的話則須人工修改。所幸在【一般使用者】的場合下,不會有太大的影響。






































    下次誰再跟我說 Insert 效能比 Append 好就踹飛他!



    See also:



    2021/09/13

    你需要處理 Unicode 編碼?在複製之前邀請你思考這個問題


    底下的程式內容到了 XE 後已經被 TEncoding 物件所取代,但這問題時常被問到,之前主流是 Base64,當時還可以用 EncdDecd 單元處理 Unicdoe 編碼,現在已逐漸改以 JSON 格式為主流,EncdDecd 單元已無法滿足眼下的需求了。

    WideString 是 Delphi 7 相容 Unicode 的字串類型,然而 WideString 並不適合作為資料傳輸,要達到良好的相容性,使用 UTF16 是比較好的選擇,可以確定的是 Delphi 7 沒有 WideString 對 JSON 的 Encode 和 Decode 的函式內容,不想自己寫?不囉嗦,直接上程式碼:

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    function DecodeUTF16(sStr: string): WideString;
    var
      i: Integer;
      StrPos: Integer;
      temp, top, last: string;
      ResultStr: WideString;
    begin
      ResultStr := '';
      repeat
        StrPos := Pos('\u', sStr) - 1;
        if StrPos < 0 then begin            // 無 unicode 編碼不需轉換
          last := sStr;
          ResultStr := ResultStr + last;
          Break;
        end;
        top := Copy(sStr, 1, StrPos);       // 取出編碼字符前非 unicode 編碼的文字,如數字
        temp := Copy(sStr, StrPos + 1, 6);  // 取出編碼,包括 \u,如\u53f0
        Delete(temp, 1, 2);
        Delete(sStr, 1, StrPos + 6);
        ResultStr := ResultStr + top + WideChar(StrToInt('$' + temp));
      until (StrPos >= 0);
      Result := ResultStr;
    end;
    
    function EdenUTF16(const sStr: WideString): string;
    var
      w: Word;
      StrPos: Integer;
      UTF16Str, TmpStr: string;
    begin
      TmpStr := '';
      for StrPos:=1 to Length(sStr) do begin
        w := Ord(sStr[StrPos]);
        UTF16Str := IntToHex(w, 4);
        TmpStr := TmpStr +'\u'+ UTF16Str;
      end;
      Result := TmpStr;
    end;
    

     

    結論時間

    以上的程式碼雖然能應用在實戰中,其 Delphi 7 裡的函式庫幾乎沒有對 WideString 處理的問題需要正視,在尋求古老三方元件的協助也無可避免需要手刻不足的區塊;自 Delphi XE 開始至現在的 Delphi 11 早已解決絕大部份 Unicode 的麻煩。若你仍有中文處理需求,真心邀請你使用 Delphi CE 社群版來進行專案提升,省下你開發的時間,專注地在商業邏輯的開發會為你帶來更好的效益,畢竟公司開來目的是為了賺錢,而非程式碼研究,研究的事我來就行。😁

    和你分享 😉

     

     

    2021/09/10

    Delphi XE 存取目錄檔案清單、和排序方式


     

    最近同事詢問到 Delphi 如何讀出檔案時間,而版本為 Delphi 7,網路資料很多,Google 一找一大把,但關於 XE 以上的新版本卻找不到什麼資料,究竟新版 Delphi 有沒有更好的解法呢?

    這問題可以拆分為:

    • 讀取目錄檔案
    • 讀取檔案時間
    • 儲存檔案清單(含時間)
    • 排序檔案清單

    有了以上步驟後,各別突破就簡單了。😉

    讀取磁碟資料在 XE 後,為了跨平台特別設計了【IOUtils】單元,目的在各家平台都能使用相同程式碼讀取其儲存媒體內容,所以 IOUtils 是非常值得投資學習的單元。

    讀取目錄檔案

    IOUtils.TDirectory 是讀取目錄結構的物件,只要使用 GetFiles 就可以讀出目錄內所有檔案,簡單程式碼如下:

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    var
      LFileList: TStringDynArray;
      LFile: string;
    begin
      LFileList := IOUtils.TDirectory.GetFiles('D:\Eden的目錄');
      for LFile in LFileList do
      begin
        ListBox1.Items.Add(LFile);
      end;
    end;
    


    讀取檔案時間

    取得檔案路徑後,就可以依序取得它們的時間,在 IOUtils 中,TFile 物件可以取得以下時間

    • GetCreationTime: 檔案建立時間
    • GetLastAccessTime: 檔案最後讀取時間
    • GetLastWriteTime: 檔案最後寫入時間

    以「檔案建立時間」為例,簡單程式碼如下:

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    var
      LFileList: TStringDynArray;
      LFile: string;
    begin
      LFileList := IOUtils.TDirectory.GetFiles('D:\Eden的目錄');
      for LFile in LFileList do
      begin
        ListBox2.Items.Add(DateTimeToStr(IOUtils.TFile.GetCreationTime(LFile)));
      end;
    end;
    


    儲存檔案清單(含時間)

    有了檔案和時間清單,就要進行兩者的結合,使用快取資料集是不錯的選擇,Delphi 內建的快取資料集有兩個:

    • TClientDataSet
    • TFdMemTable

    TFdMemTable 是比 TClientDataSet 更為輕巧的資料集物件,而 TClientDataSet 則是經典物件,選擇上看個人喜好,設計上大同小異。簡單程式碼如下:

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    var
      LFilePos: Integer;
    begin
      with ClientDataSet1.FieldDefs do
      begin
        Add('File', ftWideString, 200);
        Add('CreationTime', ftDateTime);
      end;
      ClientDataSet1.CreateDataSet;
      ClientDataSet1.LogChanges := False;
      ClientDataSet1.IndexFieldNames := 'CreationTime;File';
      for LFilePos := 0 to ListBox1.Items.Count-1 do
      begin
        ClientDataSet1.Append;
        ClientDataSet1.Fields[0].Value := ListBox1.Items[LFilePos];
        ClientDataSet1.Fields[1].Value := ListBox2.Items[LFilePos];
        ClientDataSet1.Post;
      end;
      ClientDataSet1.First;
      while not ClientDataSet1.Eof do
      begin
        ListBox3.Items.Add(Format('%s, %s', [ClientDataSet1.Fields[0].AsString, ClientDataSet1.Fields[1].AsString]));
        ClientDataSet1.Next;
      end;
    end;
    


    使用 TFdMemTable 請注意

    TFdMemTable 預設不會記錄資料歷程 (TFdMemTable.CachedUpdates default value is False),故 LogChanges 該行程式碼要刪除。


    排序檔案清單

    ClientDataSet1.IndexFieldNames 屬性設定好以時間欄位排序,即可得到理想的結果,如果要倒序,則可以參閱【【Delphi】ClientDataSet 的排序】,裡面有詳細的解說。


    資料集太大?泛型物件也可以

    如果認為資料集物件過於龐大,則可以考慮使用泛型物件,在這裡使用 Generics.Collections 單元裡的 TDictionary 物件,目的是它可以存放 Key=Value 字典,在這個場合可以存放兩種值,適合使用 TDictionary 物件。

    搭配 TArray 處理排序功能便可以取代資料集的設計方式,完整程式碼如下:


    結論時間

    在 Windows 平台下找尋 Win32 API 是一件再正常不過的事情了,但進入到 64 位元或是行動裝置等平台後,以往的開發習慣也要跟著一起改變,Delphi 隨著科技的更新也一同進步,你不需要 Win64 API、Android API、MacOS API、iOS API 等全部自行實作一次,只需要在設計程式上跟著 Delphi 轉換開發思維,如前面的範例所述,不僅僅是 API 上的改變,框架的整合應用也是重要且必學的技術,本文提供了硬體存取和資料庫存取的綜合應用,期待你的發揮 ❤


    和你分享 😉


    See also


    2021/09/07

    Delphi 10.4 Community Edition (CE) 社群版初體驗

    你遲早都要用編譯器來編譯跨平台 APP,何不現在就用最好的! 

    你開發 APP 所消耗的心力遠超過你的想像?

    以往以 Web 平台為基礎的開發框架,到最後都必須使用 NodeJS 進行編譯,看著 NodeJS 的編譯效率和 WebPack 的龐大,這還不包含配置各家平台的開發工具,你花了多少心力在「部署」你的環境? 你遲早都要用編譯器來編譯跨平台 APP 專案,何不現在就用最好的! 

    2021/09/03

    Desktop First UX Summit 2021 桌面第一高峰會


    2021 年的「桌面第一高峰會」研討會內容十分豐富,各家贊助商也來參與這難得齊聚的盛事。

    其中 Marco Cantu 提到 RAD Studio (Delphi, C++ Builder) 11 預覽版本的內容,他認為有三個值得一提的亮點:

    1. 高解析度的工具介面

    2. 隨主題變化,所見即所得的設計介面

    3. 改良 VCL TRichEdit 元件

    當然還有很多,例如 FMX 上的 TWebBrowser 在 Windows 平台上支援 WebView2 (edge) 版本等。

    研討會訴求主軸從【升級】變為【推廣】。

    感受到 EMBT 是下定決心要擺脫【老派】應用程式的惡名,未來提供教育版時,新人或學生的接受度也會提高,才不會有「現在都 202x 年了你還讓我開發 WinXP APP」的反抗心態。

    重新雕塑 VCL 和 FMX 的選擇

    VCL 重回主角身份,依舊是地表上最強的桌面開發框架無誤,FMX 持續發展,相較於 VCL 少了三方廠商的支援,FMX 不再訴求「取代 VCL」,反而比較適合作為 VCL 的延伸。

    在應用程式開發會是以 Windows 為核心,Mac 和行動裝置為延伸。對我們已有的產品來說,原有的產品提高了全功能的重要性,跨平台會以重新檢視和篩選出必要的功能實現為主軸,旨在提供使用者便利性和即時性,加強提供全方位的服務為其核心價值。

    總結

    小孩才做選擇,我全都要!

    VCL 你要學,FMX 也是必學的功課,你的薪資也莫名地變薄了呢 (誤),是說能給服務的對象更有價值的內容,才是我們作產品最大的樂趣,你說是吧!

    SEE ALSO

    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

     

     

    2021/07/21

    Delphi CE 社群版版權到期延展方法


    在【How to extend CE licence?】社群討論中顯示,當 CE 社群版的版權到期時,可以再到 Delphi 社群版下載頁面:https://www.embarcadero.com/products/delphi/starter/free-download/,使用同帳號再註冊一次,EMBT 系統會自動發送新的一組授權序號到你的信箱。

    要注意的是這組序號只能註冊當下最新版的社群版中,若版號不一樣則無法使用,此時則必須重新安裝最新版本的社群版。

    和你分享 ❤

    2021/03/23

    What is Encryption in Delphi? (2)


    DataSnap Server 有提供 PC1 加密過濾器,一開始什麼都用官方預設值,運作下沒有問題,但就是 Key 值都是固定,就來修改一下吧。

    同步修改後運作也是正常,正常的測完後,就要來試試【如果伺服端和客戶端密碼不同時會跳出什麼錯誤】。

    結果



    居然仍能運作!



    這就怪了,為什麼兩邊的 KEY 值不同卻能運作無誤?

    在經過測試後,它會經過幾個單元:

    • DBXTransport
    • DBXEncryption

    DBXEncryption.TPC1Cypher 類別裡有 Cypher / Decypher 加解密函式,就進行測試,才知道每對封包加密傳遞給對方時,KEY 也會在包在其中一同傳給對方,對方再使用該 KEY 進行封包解密,反之亦然。

    簡單的說就是:用 KEY 搭配【相同】演算法解密該封包才能夠正確解密。

     

    所以要知道正確的演算法才是關鍵,雖然只要是 Delphi 的應用程式就必定可以解開,但以 Delphi 這麼小眾的情形下也算得上一種良好的加密法則。(笑)

    See also

    2021/01/26

    Delphi 母公司 Idera 買下 Apilayer

    Apilayer 官網截圖

    Marco Cantu 今天更新了他的 Blog,提到 EMBT 母公司 Idera 最近買下【Apilayer】公司,為 Idera 事業群增添了新血。

    Apilayer 公司主要業務是【網路微服務 REST API】,範圍囊括了世界國家、國家地理位置反查等 REST API,類似【政府資料開放平臺】內容。

    教學手冊置於文末 ❤️

    Marco Cantu 也在他的 Blog 中展示如何使用 Delphi 操作 Apilayer API,提供了 Google 外另一個經濟實惠的選擇。

    大匠和你分享。❤️❤️❤️

    See also


    2021/01/22

    Delphi 經典案例分享 -- 『カラオケの鉄人』


     

    「『カラオケの鉄人』店舗で、クーポン作成 - DTP並みの印刷システム実現の手法」

    Embacadero 之前的研討會中,有一項吸引到大匠我的目光:

    『カラオケの鉄人』店舗で、クーポン作成 - DTP並みの印刷システム実現の手法

    製作【卡啦OK鐵人】的日本公司【株式会社鉄人化計画】是一間以卡啦OK為主要業務的上市公司,據點分佈在神奈川縣和千葉縣,共計超過 49 處營運據點。

    簡報內容描述店家從【Linux + Kylix】升級成【jQuery + PHP + WebBroker + FireMonkey】跨 Web 和 跨行動裝置的移殖工作。

    很多開發精華毫無保留地呈現,例如:

    • WebBroker CORS
    • JSON 和 BSON 
    • 桌面印刷(DTP) => 圖形輸出技巧
    • FMX + BARCODE

    這份簡報顛覆了我對 Delphi Web 能力的三觀,內容非常精彩,值得一看再看!

    相關資源收錄如下:

    2020/12/08

    Github DataSet Helper 試用


     在 Delphi developer FB 社團看到 DatasetHelper 開放原始碼單元。

    功能

    針對 TDataSet 進行聚集處理,如:加總 SUM、平均 AVG、計數 COUNT 等,也擴充正序 ForEach 和反序 ForEachReversed 函式讓開發者可以進一步處理每一筆資料。

    2020/09/09

    Code Insight Between Delphi 10.4.1 and Cnpack

     


    Delphi 10.4.1 的【程式碼提示功能】進行很大的改良,除了功能演算法最佳化外,對我們有什麼影響呢?

    2020/07/29

    Delphi in Depth DataSnap 網站應用程式全端開發 出版



    作者:吳祐賓





    購書連結:
    書本下載連結:PDF
    範列下載連結:Github

    內容簡介
      讓你從 0 到 1 進入全端開發領域,掌握後端知識同時也學會前端開發訣竅,點開 Web 開發新技能
       
      Delphi 進階框架 -- DataSnap 全方位構築後端知識。
      jQuery EasyUI 前端技術內涵及接近 VCL 元件的操作概念。
      資料庫常用操作。
      涵蓋語法入門,元件介紹等前後端整合實戰應用。

      給需要本書的人:
      ★有接觸過 JavaScript 卻不知道如何開始才能點開後端技能的人
      ★有接觸過 Delphi 但又不想打掉重練的人
      ★老是寫不好 Delphi 程式的人
      ★想運用 DataSnap 開發全端專案的人


    本書特色

      1.本書採漸進式開發後台管理系統的全端網站應用程式,讓學習者能馬上做,立即學。
      2.全書程式碼毫無保留的呈現,重點處還會節錄再說明,更加強化理解與記憶內容。
      3.提供關於框架原理的圖說,讓讀者更能聚焦學習重點上。
      4.實作成品能立即應用在實戰中,實現超速學習成果。

    專文推薦

        Eden 是我見過對 Delphi 最有愛的工程師,沒有之一。__【Delphi.KTOP 資深版主 Jason Wong】
       
        Eden 的堅持,是目前台灣地區 Delphi 不可或缺的精神,我從這本書裡面看到 Eden 的用心。__【Indy TIdDNSServer、Delphi / Kylix -Indy 網路程式設計作者 張子仁】

        本書從前端的 Javascript 說起,漸近地深入後端 DataSnap 實作,最後將前後端串起來,這樣的佈局,尤其對全端不熟的開發者而言,相信可以很快速的入門與應用 !__【Delphi.KTOP 副站長 蕭沖】


     到 Google Play 看看

    到 Pubu 商城看看



    2020/03/04

    外掛小幫手FastReport

    原來是報表工具啊,我還以為是外掛開發程式呢! (笑)


    Delphi最有趣的地方是它有很多三方元件可以支撐開發專案,以上圖為例,功能不多,通常列為小專案,這時使用諾大的Delphi開發專案顯得太小題大作。


    這時FastReport就派上用場,FastReport雖然是報表工具,別小看它,它搭載的Report Designer備有Pascal直譯功能,還有內建VCL基礎元件,有效利用下,可以大幅減少小專案開發時間,還能降低Delphi升級所帶來的改版衝擊呢!


    報表工具當然要著重在報表的設計,Report Designer提供的函式庫想當然是不夠使用。FastReport也明白這點,便在FR Document也寫了很多的輔助說明,在藉助FR Document的神奇力量後,我也添加了許多常用函式到Report Desinger中,開發起來便利度提高非常多!


    除了可視元件外,像是常常用到的TStringList基礎類別也有提供,程式寫起來超安心。


    還有ADO, DBX等資料庫元件,用了Report Designer,很多小型專案都在移轉到FR後就刪除,專案存放目錄差點手殘到刪光光!


    和Delphi一樣可以下中斷點,這Debug很可以。

    一想到Delphi要開個幾十秒,開啟FastReport Report Designer不僅快,刻起程式也是趣味十足,提供各位參考。


    See also

    購買連結:Fast-Report官方網站