Question

Récemment, j'ai eu du mal à exposer des événements de .NET à COM.

J'ai réussi à utiliser cet exemple (extrait conceptuellement de http://blogs.msdn.com/andreww/archive/2008/10/13/exposing-events-from-managed-add-in-objects.aspx ):

// Type de délégué pour notre événement personnalisé.

[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);
        }
    }
}

Cela fonctionne bien car l'interface IAddInEvents est définie en tant que IDispatch . Cependant, je dois publier une interface de source d'événements qui est IUnknown . Je n'ai pas le contrôle sur l'interface d'événement, car elle provient d'une bibliothèque tierce (qui sera également le consommateur des événements publiés). Chaque fois que j'essaie de m'accrocher aux événements, l'environnement VB (où j'essaie de les absorber) se bloque, tout comme l'environnement VBA utilisé par le produit tiers (ESRI ArcMap).

J'ai pu implémenter (partiellement) l'implémentation de l'interface IConnectionPointContainer (que COM utilise en arrière-plan pour gérer les événements) manuellement, puis je peux absorber l'événement et entrer dans mon implémentation IConnectionPointContainer. Cependant, cela me semble exagéré et je pense qu’il faut un support implicite pour cela dans .NET. Deuxièmement, avec cette approche, je perds instantanément le soutien des délégués.

Quelqu'un at-il une expérience avec cela? Merci d'avance.

Était-ce utile?

La solution 2

Ok, j’ai pu le faire en implémentant les ports COM classiques IConnectionPointCointainer, IConnectionPoint et IConnection (plus les interfaces d’énumération). Il ne s'intègre pas dans le modèle de délégué / événement .NET, mais fonctionne.

Autres conseils

Tout simplement, vous ne pourrez pas faire cela. Classic VB ne prend pas en charge les COM non automatisés (comme vous l'avez vu).

Vous devrez disposer d'un wrapper que vous pourrez transmettre à votre instance Automation et qui publiera l'événement non-Automation. En réalité, vous devrez disposer de deux types distincts pour gérer les deux clients distincts des événements (activé et non automatisé).

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top