2009-07-09 38 views
2

這與another Delphi-version question有關,但仍然不同;如何檢測特定的Delphi版本?

我正在尋找一種方法來檢測編譯我的代碼的Delphi編譯器的服務包(或內部版本號)。 jedi.inc很好,但它並沒有告訴我確切的版本。 (我不能使用那裏的SUPPORTS_ *定義,因爲那些也是與版本有關的)

我需要這個,因爲一些bug在舊版本中存在(在這種情況下,它是一個_ValLong bug in Delphi 2009)一個更高版本的服務包(在這種情況下爲Delphi 2009服務包3)。

目前,我有各種檢查在我的代碼,像這樣:

{$ IFDEF BUG_QC_68123}

但我不能說這在我的主要包括文件:

{$IFDEF DELPHI2009_UP} 
    {$DEFINE BUG_QC_68123} 
{$ENDIF} 

...因爲這會錯過D2009SP3和更高版本不再有這個錯誤的事實。

任何想法? PS:這可能也適用於Delphi的舊版本(和更新版本),所以任何庫和/或組件供應商都會對此感興趣,我猜想。

回答

1

你可以嘗試,包括軟件編譯器文件版本。例如,DCC32.exe上有一個文件版本,可以通過編程獲取,然後以const的形式寫入單元。這可以作爲構建過程的一部分來完成,因此在構建應用程序之前它會獲取版本信息(這對於類似FinalBuilder的事情很容易)。

我已經做到了這一點其他的東西,使我們關於屏幕上我們可以得到有用的信息各個位。另外,當我們的應用程序出現錯誤時,我們可以將此信息捆綁到我們的EurekaLog錯誤報告中。

但是我不知道是否在DCC32.exe的文件版本與每德爾福更新而更新。

3

不幸的是,像System.pas中的RTLVersion這樣的常量沒有在更新中更新,但我認爲如果有人想爲它做一個QC條目,這將是一個很好的建議。

如果您正在測試的錯誤可以在代碼中重現,您可以隨時在啓動時測試它們並設置您自己的全局標誌。

我通過確保始終應用最新更新來解決這些差異。我還沒有遇到一個案例,那裏的更新是不穩定的,迫使我把它推回去。至少不用Delphi。

5

有每個版本定義的符號:

VER80 - Delphi 1 
VER90 - Delphi 2 
VER100 - Delphi 3 
VER120 - Delphi 4 
VER130 - Delphi 5 
VER140 - Delphi 6 
VER150 - Delphi 7 
VER160 - Delphi 8 
VER170 - Delphi 2005 
VER180 - Delphi 2006 
VER180 - Delphi 2007 
VER185 - Delphi 2007 (Note: symbol VER185, for example, is used to indicate Delphi 2007 compiler or an earlier version.) 
VER190 - Delphi 2007 for .NET 
VER200 - C++ Builder 2009 
VER210 - Delphi 2010 
VER220 - Delphi XE 
VER230 - Delphi XE2 
VER240 - Delphi XE3 
VER250 - Delphi XE4 
VER260 - Delphi XE5 
VER270 - Delphi XE6 
VER280 - Delphi XE7 
WIN32 - Indicates that the operating environment is the Win32 API. 
LINUX - Indicates that the operating environment is Linux 
MSWINDOWS - Indicates that the operating environment is the MS Windows/li] 
CONSOLE - Indicates that an application is being compiled as a console application 

Source Another source 不能檢查不同的版本號。

而好奇的是,VER10-VER70在Turbo Pascal版本中,VER110是C++ builder版本。

+0

VER190 = Delphi.NET 2007 VER200 = 2009的Delphi CIL = Delphi.NET – 2009-07-09 20:48:57

1

編譯器不公開該信息。它只會告訴你主要版本,當應用更新時它不會改變。

我認爲你可以做的最好的事情是總是爲最新的更新編寫代碼。假設您的代碼的消費者也將擁有最新的更新。如果他們不這樣做,那麼這是他們自己的錯,而不是問題需要擔心。在你的系統需求中提到它。當然,你的代碼不適合他們,但其他人也不會,因爲他們仍在使用已知錯誤的代碼。

下一個最佳選擇是編寫假設已應用更新。也就是說,編寫代碼就好像所有已知的錯誤仍然存​​在。缺點是你的代碼可能無法正常運行,所以每個通過升級來做正確事情的人都會因爲繼續擁有不理想的代碼而受到懲罰。