Rules for AddIn Event Parameters

Latest post 07-16-2008 2:08 PM by Melody. 1 replies.
  • 07-15-2008 3:21 PM

    • Terry
    • Top 10 Contributor
    • Joined on 05-10-2006
    • Posts 90

    Rules for AddIn Event Parameters

    I'm back!  No, no... please don't get up.

    So I've got VSTA completely embedded in our application and it actually seems to be working consistently.  Of coruse there are issues to deal with still but given the complexity of our implementation I'm pleased.

    Now, I seem to thing that I knew the answer to this a while back but I can't remember any more.  what are the rules for what types of parameters you can and can't use in an AddIn Event?

    More specifically, I have an event that passes a custom object (FieldEventArgs) as the second parameter.  This object inherits from System.EventArgs like it's supposed to and almost all the properties are accessible just fine from the AddIn code.  Of course they are all strings except one.  One of the properties of this object is an XmlElement.  When I try to access it, I get an error "Return argument has an invalid type."  Is this breaking some rule about what can and can't be used across the pipeline?

    Is it just as simple as teh fact that XmlElement isn't serializable?

    Thx.

  • 07-16-2008 2:08 PM In reply to

    • Melody
    • Top 10 Contributor
    • Joined on 04-26-2007
    • Syracuse, NY
    • Posts 246

    Re: Rules for AddIn Event Parameters

    Terry,
    >So I've got VSTA completely embedded in our application and it actually seems to be working consistently.
    Great!

    > what are the rules for what types of parameters you can and can't use in an AddIn Event?
    Same rules as passing anything else.

    >This object inherits from System.EventArgs
    Good programming practice; however, System.EventArgs are a special case for VSTA/ProxyGen and the inheritence is removed.

    >One of the properties of this object is an XmlElement.  When I try to access it, I get an error "Return argument has an invalid type."  Is this breaking some rule about what can and can't be used across the pipeline?
    >Is it just as simple as teh fact that XmlElement isn't serializable?
    Pretty much.  The options that you have for this are to exclude that property, wrap it into a serializable/MBRO class, or convert it to something that is serializable or MBRO and pass that isntead (like using XmlElement.ToString()).  If a System.Xml.Linq.XElement would work for you, that type is XmlSerializable so you should be able to pass it like a struct (excluding the type from the descriptor file then copying the implementation into the proxy like the ShapeAppBasic samples).

    Hope this helps. 
    Thanks,
    -Melody

Page 1 of 1 (2 items) | RSS
Copyright Summit Software Company, 2008. All rights reserved.