1

最近、.NET から COM にイベントを公開する際に問題が発生しています。

私はこの例で成功しました (概念的にはhttp://blogs.msdn.com/andreww/archive/2008/10/13/exposing-events-from-managed-add-in-objects.aspxから取得):

// カスタム イベントのデリゲート タイプ。

[ComVisible(false)]
public delegate void SomeEventHandler(object sender, EventArgs e);

// Outgoing (source/event) interface.
[ComVisible(true)]
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
public interface IAddInEvents
{
    [DispId(1)]
    void SomeEvent(object sender, EventArgs e);
}

[ComVisible(true)]
[ClassInterface(ClassInterfaceType.None)]
[ComSourceInterfaces(typeof(IAddInEvents))]
public class AddInUtilities :
{       
    // Event field. This is what a COM client will hook up
    // their sink to.
    public event SomeEventHandler SomeEvent;

    inernal void FireEvent(object sender, EventArgs e)
    {
        if (SomeEvent != null)
        {
            SomeEvent(sender, e);
        }
    }
}

IAddInEvents インターフェイスはIDispatchとして定義されているため、これは正常に機能します。ただし、IUnknown であるイベント ソース インターフェイスを公開する必要があります。イベント インターフェイスはサード パーティのライブラリ (発行されたイベントのコンシューマーにもなります) からのものであるため、私は制御できません。イベントにフックしようとすると、VB 環境 (イベントをシンクしようとしている場所) がクラッシュし、サードパーティ製品 (ESRI ArcMap) が使用する VBA 環境もクラッシュします。

IConnectionPointContainerインターフェイス (COM がバックグラウンドでイベントを処理するために使用する) を手動で(部分的に) 実装することができたので、イベントをシンクして IConnectionPointContainer 実装にステップインすることができました。しかし、これはやり過ぎのように思えます。.NET ではこれを暗黙的にサポートする必要があると思います。第二に、このアプローチでは、デリゲートのサポートが即座に失われます。

誰もこれについて経験がありますか？前もって感謝します。

4

2 に答える 2

2

簡単に言えば、これを行うことはできません。従来の VB は非オートメーション COM をサポートしていません (ご覧のとおり)。

非オートメーション イベントを公開するオートメーション インスタンスを渡すことができるラッパーが必要です。イベントの 2 つの個別のクライアント (自動化が有効なクライアントと自動化が有効でないクライアント) を処理するには、実質的に 2 つの個別の型が必要になります。

于 2009-01-07T19:05:55.867 に答える
1

さて、これは、従来のCOM IConnectionPointCointainer、IConnectionPoint、およびIConnection（および列挙型インターフェイス）を実装することで実現できました。.NETデリゲート/イベントモデルには統合されませんが、機能します。

于 2009-01-19T17:33:44.733 に答える