將Delphi 2006應用程序移植到XE

我想將幾個大型應用程序從Delphi 2006移植到XE。原因不在於使用Unicode，而是爲了利用（希望）更好的IDE穩定性，本地PNG支持，更多組件，更少的VCL bug，更少依賴第三方的東西，減少對你們的影響等。的應用程序可能受益於Unicode，但目前這不是問題。目前我只想採取最直接的方法讓他們再次編譯。作爲開始，我已經將所有含糊不清的字符串聲明，即字符串改爲AnsiString或ShortString，將字符串改爲AnsiChar，並將pChar改爲pAnsiChar，然後用D2006重新編譯。到現在爲止還挺好。沒有什麼破壞將Delphi 2006應用程序移植到XE

我的問題是：從哪裏來？假設我只是向XE編譯器提供消息來源並點亮觸摸紙，那麼可能是什麼問題呢？

例如，

var 
    S : AnsiString ; 
... 
MainForm.Caption := S ;

這是否會產生一個錯誤？一個警告？我假設VCL現在是Unicode，還是將XE拉入非Unicode組件，或者轉換字符串？在XE中保留使用8位字符串的應用程序實際上是否可行？還是會有太多令人頭痛的問題？

如果最好的/最簡單的方法是Unicode，我會這樣做，即使我不會使用擴展字符，至少在不久的將來。

我想知道的另一件事是第三方的東西。我想我需要獲得與XE兼容的更新版本。

任何（肯定！）評論贊賞。

來源

2012-05-22 rossmcm

現在VCL完全是Unicode，所以你顯示的代碼將生成一個編譯器警告，而不是一個錯誤，關於從AnsiString到到UnicodeString的隱式轉換。如果AnsiString包含非ASCII字符（編譯器無法驗證），那麼這是一種潛在的有損轉換。如果繼續使用AnsiString，那麼你必須做一個明確的類型轉換，以避免該警告：

var 
    S : AnsiString ; 
... 
MainForm.Caption := String(S);

你是最好的關閉不是ANSI-fying你這樣的代碼。擁抱Unicode。您的代碼將更容易管理，並且對未來的版本和平臺而言，它將更具可移植性。您應該將AnsiString的用法限制在Ansi實際需要的地方 - 網絡通信，傳統數據的文件I/O等。如果要將內存保存在應用程序中，尤其是僅在使用ASCII字符時，請使用UTF8StringAnsiString。 UTF-8是Unicode的8位編碼，並且UTF8String和UnicodeString之間的轉換無損失，無編譯器警告。

來源

2012-05-22 17:34:55

謝謝@Remy。從全球範圍的'AnsiString'回到'String'沒什麼大不了的（FART是一個很棒的工具）。有合理數量的代碼需要並採用字節大小的ASCII字符串。如果我將所有聲明都還原爲「字符串」，則XE將假定UnicodeString。當我編寫類似'if（S [3] ='：'）然後...'的代碼時它會警告我嗎？這是我不想忽視的情況。 – rossmcm

''：'是字符文字。字符文字和字符串文字現在是上下文相關的。當與'UnicodeString'使用的，將文字是Unicode（在'＃XX' 2位數中的'＃的範圍內字面的特定情況下80'-'＃FF'，其Unicode表示是由新的影響'HIGHCHARUNICODE'編譯器指令）。 'String'，'Char'和'PChar'現在都是Unicode。如果'S'是一個'UnicodeString'，那麼你將比較'WideChar'和'WideChar'。如果'S'是'AnsiString'，那麼你會比較'AnsiChar'和'AnsiChar'。在這兩種情況下，都不需要編譯器警告。 –

好的。 @Remy我的觀點是，如果我有現有的代碼：'var S：string;開始S：='你好'; Writeln（SomeTextFile，S）;'和文件需要8位ASCII和包含字節'$ 68 $ 65 $ 6C，$ 6C，$ 5F，$ 0D，$ 0A'後代碼執行時，XE編譯器不會警告我會將S視爲Unicode而不是Asni，並且文件內容將會不同（並且錯誤）？我理解正確嗎？ – rossmcm

這是一個跳遠以2006年到2011

但如果你認爲這是可能的：

您可以選擇使用新的轉換方法，將字符串變量;
你必須檢查2006年和xe之間的所有版本，以瞭解庫如何改變，因爲有些已經被抽出，其他人被合併，並且被刪除了一些;
您必須購買/下載第三方組件的升級（如果有）。

來源

2012-06-30 00:41:47 PSyLoCKe

將Delphi 2006應用程序移植到XE

回答

相關問題