MetaEdit+ already guides users on which relationships are legal between which objects. The modeler selects the objects he wants to connect, and optionally also the relationship type he wants, and MetaEdit+ creates roles and relationships of the correct types. If there is more than one legal combination for the selected objects, MetaEdit+ prompts the modeler to choose from a list of the possibilities.

 

What you mention in your email tries to achieve the same goal by a different route: when the user has chosen one object and also the relationship type, highlight all the other objects of any type from which a legal combination could be made.

 

I've seen other tools go even further: you select one object and a relationship type, and the tool offers to create a new object and a relationship to it. That tends to be seen in tools with a weak or naive idea of a graph, where objects can't exist unless they are connected into some structure with other objects, often a tree.

 

Our approach mirrors the way modelers work: they know the objects without really thinking, but the exact types of the relationships and roles are not always as intuitive. For instance in a family tree, everyone can select objects called "Mum" and "Dad", but they won't necessarily know what names the metamodeler has given to the relationship and role types to connect them: Parent, Spouse, Wife, Mother, Father etc. Or in UML, you can select "Car" and "Wheel", but then have to think if you want an Aggregation or Association between them.

 

Our approach also copes fine with n-ary relationships and large graphs; imagine yours applied to a large UML class diagram or family tree -- pretty much every object would often be highlighted, which isn't really offering any guidance.

 

Have you thought through what should happen in your case if there are multiple graphs open, each with an object and relationship type selected? Or multiple objects selected in one graph? Or two diagrams open on the same graph, but with different selections in each? Or a matrix? MetaEdit+ already works with all of those cases. They are also good examples why we don't provide an API command "selectedObject" or "currentRelationshipType" - there is no single answer to that.

 

What can be done is to use copiedObjects:

That still leaves you without the relationship type and graph, but you could make the next step be to run a generator (which will give you the graph) that calls your API function. That can then figure out the legal relationship types for the selected object(s), and offer to create new relationships and possibly objects based on that, or then highlight some other objects. I'm pretty sure the end result will be longer and more complicated for the modeler (not to mention for you!) than what MetaEdit+ already offers, but then that too is a perfectly valid research result!

 

The API is intended for users to be able to add new behaviour, not to change existing MetaEdit+ behaviour. As such, it is based on data integration rather than control integration -- only about 4% of the API methods are for control. Maybe you can restate your problem so its input is in the form of model data, rather than the ephemeral state of windows? E.g. as I mentioned above, copy an object in MetaEdit+ and let the relationship selection happen in your API program.

 

stevek wrote: The API is intended for users to be able to add new behaviour, not to change existing MetaEdit+ behaviour. As such, it is based on data integration rather than control integration -- only about 4% of the API methods are for control. Maybe you can restate your problem so its input is in the form of model data, rather than the ephemeral state of windows? E.g. as I mentioned above, copy an object in MetaEdit+ and let the relationship selection happen in your API program.

Sorry, but I think copying an object is not really an option, because it is not really an intuitive step in modeling when trying to add a new relationship.

Regards,
Dagi

Yours,

Juha-Pekka