如何連接德爾福.NET對象

Question

我有COM或連接的充分了解的* .dll與LoadLibrary和GetProcess等

一個人如何在.NET連接類結構或物體進入德爾福代碼，以便編譯器和編輯器可以連接/關聯到.net？

就像Delphi使用（cdecl）或（stdcall）連接到以不同方式構建的方法。我們在.net中有不同的班級聲明嗎？

.net和Delphi之間的內存管理有所不同嗎？ Lex Dean。

Lex Dean。

Answer 1

有一些方法可以從非託管代碼調用託管代碼。最簡單的方法是從.NET代碼公開COM API。看看[鏈接] [1]

[1]：http://msdn.microsoft.com/en-us/library/ms973872.aspx的概述託管/非託管代碼的互操作性

Answer 2

我找不到如何迴應還 我知道別人會看你的意見。感謝MSDN網頁，我無法找到它作爲MSDN庫，因爲它非常大。現在，如果我離開目標或跟蹤側面，請糾正我。

在德爾福，我們有'項目/導入類型庫'從腳本，ActiveX幾乎所有的MS產品，MS有史以來爲windows導入許多東西。 Delphi 4支持File/New來打開對話框，ActiveX選項卡包含用於多個對象的「COM對象嚮導」。我們有效地使用Delphi中的接口和對象來創建MS類型庫中的對象。就我個人而言，我從來沒有使用它，但德爾福豐富的這些方法。從你給我的網頁上可以看到，MS說從一個'.net類型庫'導入到Delphi中，一個連接到達。從MSDN建議作爲一種更強大的方式在Delphi中是建立一個DotNet.pas文件來鏈接到.Net框架作爲一個COM連接，這一直在我心中一直。我的想法已經從根本上重建windows.pas。或者，他們還有更好的方法來獲得強大的.net，並降低指令數量來訪問對象和方法。
我也在Delphi中發現： - IFormDesigner。而且我有問題，例如在調用時將內存分配給.net對象。以及如何連接到對象的方法。我不確定是開始還是結束，因爲沒有任何信息記錄在互聯網上，以我的知識來讓我開始。所以這就像在某種程度上潛入黑暗中一樣。 同時掌握一些像IUnknown，IDispatch，ISupportErrorInfo，IMarshal這樣的子對象和像dispinterface這樣的保留字也是一個學習曲線。在Delphi中沒有記錄其中的一些子對象。我明白HRESULT是用於錯誤檢查的目的，而GetLastWin32Error是從COM對象GetLastError繼承而來的。 IntPtr對我來說是新的，我猜是Delphi中的PChar。有時候提到德爾福的自動化對象有點複雜，需要以我需要思考的方式來看待。但是當你在學習的時候，你會傾向於傾向於你。我蟎需要使用它們，我的問題是安全的方式來測試一個新的對象與德爾福的小錯誤支持一直崩潰的Delphi編輯器。

Answer 3

我一直在測試AtoZed的「CrossTalk」產品，以便直接從Delphi7爲我們的產品調用.Net。 （這些電話是圍繞Atalasoft DotNet圖像庫的.Net 4包裝，從上傳的多頁PDF中提取和檢索一些最終用戶財務應用程序格式的TIFF圖像）。

有一些限制（處理一些.Net集合的問題），但整體CrossTalk似乎到目前爲止工作。 （在做出買/不買的決定之前，我仍然需要測試資源泄漏等）。到目前爲止我所遇到的任何限制，我都可以通過修改。在供應商的界面上封裝了一些包裝，將問題對象（比如泛型集合）重新格式化爲Delphi方面更容易使用的東西。

如果您遇到像D7這樣的Delphi的舊版本，那麼您還需要解決語法限制，這些語法限制在D2006/D2007及更高版本等較新版本的Delphi版本中不會看到。到目前爲止我看到的最糟糕的是.Net類級別的靜態函數，屬性和過程被轉換爲「static」關鍵字;哪些D7不明白，但德爾福的哪些後續版本。爲了解決這個問題，當你的最終目標是第三方代碼時，你將再次需要修改一個自定義的.Net包裝器來圍繞實際的目標，以避免這個問題出現。現在我的評估已經超越了功能集到性能上，到目前爲止我看到的最大問題是每次調用的性能很低，大約爲百分之八毫秒。在一臺WinXP虛擬機上的一個探查器下調用（這會降低速度）。如果您在每次使用的邊界上撥打的呼叫數量相對較少，這可能不是問題。但是當我測試從.Net到Delphi的邊界跨越1MB .Net字節數組，然後在Delphi For循環中使用轉換的ByteArray.Get_Item索引訪問來訪問.Net數組的每個字節，以將其複製到相應的Delphi字節數組用於Delphi GUI控件，額外的開銷導致了一個重大問題。那小0.08毫秒。每次通話時間的開銷爲1百萬「對於」整個.Net-Delphi邊界的循環訪問加起來將近8秒。 （使用COM傳遞字節數組時，該特定功能測試運行得更快）。

讓Delphi代碼調用轉換後的.Net System.Drawing.Image的「Save」（ToFile）方法並擁有Delphi TImage「LoadFromFile」實際上要比執行移動所需的1M訪問要快得多字節數組一次一個元素，但全部在內存中。

我正在與AtoZed支持部門合作解決這個問題，看看是否有解決方法，並在他們有足夠的時間解決問題後發佈結果。 1MB字節數組是掃描表格圖像的主體。

我希望與他們一起解決這個問題的偉大的事情和原因是，你的Delphi代碼可以創建，使用和處理本地.Net對象，而不必處理任何可以通過COM編組的東西邊界。 （我在網上看到有關使用COM進行交叉工具交互的資源泄漏的投訴，因爲在網絡端處理對象時出現問題。也許這是由於糟糕的代碼，但這是需要考慮的。）不必處理使用用於跨COM編組數組的SafeArrays，併爲每個自定義業務對象分離接口。 CrossTalk還需要處理必須標記所有.Net程序集ComVisible的問題，如果無法控制它們相對於Delphi代碼的位置，則必須將.Net COM程序集安裝到GAC中。

使用CrossTalk，您可以瀏覽每個需要使用類或方法的程序集。不要忘記，你還需要明確地瀏覽並從系統程序集中引入類，例如mscorlib，system，system.drawing等。

如果你的用例不跨越邊界調用大量次，至少看起來可能是值得的。我在http://www.managed-vcl.com網站上找到了另一個類似的產品，但與作者聯繫有點困難，所以我從來沒有完全評估過這種方法。