我已經看到,Delphi中的大多數組件(VCL)分爲兩部分。
1)設計時包
2)運行時包
在德爾福運行時間和設計時間包的故事
爲什麼這些麻煩。如果將RunTime和DesignTime軟件包合併成一個軟件包,它們會有什麼不同?
我從來沒有真正能夠理解這種分離邏輯。
那麼這背後的邏輯是什麼?
有一次,我曾經有人提到這種區分是爲了避免採用和遵循Microsoft制定的組件標準。真的,這背後沒有任何邏輯。
這是真的嗎?
我已經看到,Delphi中的大多數組件(VCL)分爲兩部分。
1)設計時包
2)運行時包
在德爾福運行時間和設計時間包的故事
爲什麼這些麻煩。如果將RunTime和DesignTime軟件包合併成一個軟件包,它們會有什麼不同?
我從來沒有真正能夠理解這種分離邏輯。
那麼這背後的邏輯是什麼?
有一次,我曾經有人提到這種區分是爲了避免採用和遵循Microsoft制定的組件標準。真的,這背後沒有任何邏輯。
這是真的嗎?
答:某些組件具有大型且複雜的設計時功能,如屬性編輯器,您可能不希望將它們包含在運行時應用程序中。
B.一些組件供應商不希望授權他們龐大而複雜的設計時功能以實現免版稅的運行時使用,但限制它們僅供開發人員使用。
邏輯就是讓自己的代碼與「膠水」代碼分開,這使得在IDE中易於使用&。
如果你做的一點點研究,你必須this SO question問不到2天前發現...
前面已經解釋的主要原因是,你可以不包括任何德爾福設計單位在運行時包。無論如何,沒有理由使用只能在IDE中運行的代碼來擴展可執行文件。
點A:如果說例如DesignTime和RunTime包包含在編譯EXE中會發生什麼?我現在問這個問題,因爲在任何給定的時間,幾乎總是有足夠的內存空間,因此內存不再是限制。 我同意B點的程度,但對於一個好的程序員來說,實現不允許在RunTime期間加載DesignTime接口的邏輯是一項小任務。 COM組件一直沒有任何問題。 – 2009-04-20 11:16:37
是否使用designtime單位在編譯時解析,而不是在運行時解析。包是靜態鏈接的DLL。因此使用包使得你的目標可執行文件依賴於它們,即。如果沒有找到所有依賴關係,Windows將無法加載並運行可執行文件。 – 2009-04-20 11:25:43
我不這麼認爲,因爲如果Packages是靜態鏈接的,那麼需要找到所有依賴關係? – 2009-04-20 11:27:45