Disable Connection point from ModelObject

Mar 27, 2014 at 2:05 PM
Hi,

I'd like to know if it is possible, in any ways, to disable a connection point (of a plannar shape) from the Model side (i.e. the ModelObjectBase associated with the shape).

In order to understand the whole thing I should put a bit of a context:
My shapes are "devices" with "ports" (connection points) and I would like my user to be able to disable ports of a device. As there is a whole logic behind these objects (port type, link type, ...) I need a ModelObject to be associated both with my plannar and linear shapes. It is then from the ModelObject that I can say if a port is available or not.

Thanks in advance for your answers and don't hesitate to ask for more details if I was not clear enough.
Coordinator
Mar 27, 2014 at 3:46 PM
Edited Mar 27, 2014 at 3:49 PM
Hi roux1max,

you can define a connection point mapping that maps a connection point of the shape to a terminal of the model object. All connection points that have no mapping are disabled.
You can define the mapping with NShape Designer (in case you use a template project) or via code:
    Template boxTemplate = project.Repository.GetTemplate("Box");
    boxTemplate.Shape.ModelObject = myModelObject;
    // Map terminal '1' of the template's model object to the MiddleLeft connection 
    // point of the box shape.
    boxTemplate.MapTerminal(1, RectangleBase.ControlPointIds.MiddleLeftControlPoint);
Best regards,
Kurt
Mar 27, 2014 at 3:53 PM
Thanks for the answer but it is not really what I needed.

I already know this way to disable a connection point but in order to do so, I need the template of the shape which I cannot get from the ModelObject side. What I wanted to know is how the HasControlPointCapability() method of a shape can use a value from its associated ModelObject to disable a connection point.

PS : I don't want the shape library to reference the ModelObject library so I cannot use a custom property of my ModelObject.
Coordinator
Mar 27, 2014 at 4:36 PM
Is the decision whether a terminal is a port or not a dynamic decision or a static decision?
Does "IsPort" depend on the state of the model object or does it only depend on the attached type of shape (linear shape or planar shape)?

In case of a static decision, I'm thinking of a solution like
  • your application sets up all templates of the project (or loads a default project)
  • while creating the templates, your application assigns instances of your model object to both, linear shapes and planar shapes
  • For each linear shape template, it creates the terminal mappings to ControlPointId.FirstVertex and ControlPointId.LastVertex of the line
  • and for each planar shape template, it creates terminal mappings for all relevant connection points of the planar shapes
  • Afterwards, you can create the diagrams using the templates for shape creation.
roux1max wrote:
(...) I need the template of the shape which I cannot get from the ModelObject side.
You can get the template from the model object side:
The IModelObject has a property IEnumerable<Shape> Shapes which returns the shapes attached to the model object.
The Shape base class has a property Template that returns the template of the shape.

roux1max wrote:
What I wanted to know is how the HasControlPointCapability() method of a shape can use a value from its associated ModelObject to disable a connection point.
If you cannot use other properties than the GeneralModelObject's properties, I don't think so.


Hope this helps,
Kurt
Marked as answer by roux1max on 3/31/2014 at 7:38 AM
Mar 27, 2014 at 5:01 PM
Thanks for your answer.
The decision is dynamic and the result only depends on the model object state, that's why I am stuck.

That's right that I did not think about the "Shapes" property of the model object, that could be a good point to dig.

Well I guess that I will have no choices but to link my model object library to my shape library.
Mar 31, 2014 at 3:38 PM
Ok, I succeeded to do so by accessing the template of the shape through the Shapes property of my model object (just as you said). Then a little bit of magic on the TerminalId mappings did the job.