Is EA.Element derived from System.IEquatable?

[Stephanie]

Hi,

There is the (desperate) Newbie again ;-).

Iam developing an Addin in C# with VS .Net 2005.

I would like to use a generic Graph data structure  (found in WWW) to store the subelements (EA-Elements) of a structured activity.

This generic requires that the conrete data implements the System.IEquatable interface (see below).

public class Graph<T,E> : ICollection<T>
   where T: IEquatable<T>

Since EA.Element provides an " bool equals(object o)" method, I expected the Comstraint is fulfilled.

However when I want to use the Graph generic for EA.ELements, in the following way:

  Graph<EA.Element, EA.Connector> activity = new Graph<EA.Element, EA.Connector>();

I get the following compiler error:

<<The type "EA.Element" must be convertible to "System.IEquatable<EA.Element>" in order to use it as parameter "T" in the generic type or method "Graph<T, E>" >>

I am not only a newbie to EA automation interface but to C#, too, so I really need your help here. What am I doing wrong, and how can I use EA.Element with this data structure?

[«Midnight»]

Stephanie,

EA uses a COM model, and is such not derived from any .Net base class.

When using EA with .Net most entities will be wrapped by the Interop assembly provided with EA. However, you'll quickly notice some limitations. In general these are the kinds of things you run into with other COM interfaces.

Still, in your particular case you can either go about this without using IEquatable, or you can write your own wrapper class. The latter option is not as daunting as it sounds, and if you put this in its own DLL (perhaps with other such EA wrappers you create) you'll only have to do it once.

HTH, David

[Stephanie]

First of all, Thanks for your help.
You convinced me to write a wrapper class, but here again a new question comes up?

Which class should I extend, from which class can I inherit EA.Element properties (members). I thought that EA.ElementClass is the one, but it has no constructors (this is at least, what the compiler says).
Am I on the right track, and where can I find more information about ELementClass?

Thanks for making newbie's life a bit easier on this rainy day.

[«Midnight»]

OK Stephanie,

One approach - there are certainly others - is...

Rather than extending from direct inheritance, consider creating a class with a private attribute that references an EA Element. You can now expose various properties and methods to manipulate the internal Element.

You can also assure that the Element class is cleaned up by disposing of it properly within your class.

Once you've gotten that far it should not be too much trouble to build similar (and simpler) wrappers for collections and such.

Now you are in a position to build hierarchies of Element sub-types, either as interfaces or classes, as best suits you preferred framework or preference. Remember to restrict these to what you currently need, at least at the beginning, or you'll spend a long in this stage.

Then (or even before then) you can create factory classes.

At this point you should be well on your way.

The above sounds like a lot of work. Don't let that overwhelm you. Take a moment to think it out, using a very restricted initial set of classes. Diagram the result as a class model in EA. Now have EA generate the spine of the (structural) code for you. Magic! You can even reverse engineer your stuff back into EA early in the game. This will get your code into the model. More magic!

HTH, David

[PS: And yes, I understand. Where I live rain is a fact of life, once the snow melts.]

[Stephanie]

David, that helped a lot.