Home » Modeling » GMF (Graphical Modeling Framework) » Custom connection figure
| Custom connection figure [message #154655] |
Wed, 10 October 2007 07:25  |
Eclipse User |
|
|
|
Originally posted by: marsha.rohrer.swisscom.com
Hi
For my application I need to define a custom connection figure that looks
like follows:
1) ******* 2) -------------->
* * |
------* *-----> or *******
* * * *
******* * *
*******
Id prefere the second one but the first one should do as well.
Comments to the first one:
There are two different possibilities. The first one is that the
connection is defined as shown above and the rectangle is a compartment in
order that oder elements can be placed in it. The second one is that the
rectangle melts with the line as soon as placed on the connection.
Comments to the second one:
Here the idea is that first the line (connection) is drawn then the other
figure (rectangle with the linking-line) can be hooked to the line.
My problems for both ideas is that I don't know how to define a child
element for the PolylineConnection.
Is there a possibility to do this with the configuration files of GMF? Or
do I have to write this extension on my own?
If I have to write it on my own how do I have to do this, which classes
need to be extended?
Any hint is welcom, I'm looking for a solution for quite a long time
already...
Thanks a lot
Marsha
|
|
|
| Re: Custom connection figure [message #154672 is a reply to message #154655] |
Wed, 10 October 2007 08:39  |
| Eclipse User |
|
|
|
Originally posted by: tobk.gmx.de
I'm not sure about the first one, but the second one should go:
In GMF 2 (and with a little hacking in GMF 1, too) it is possible to connect
connections to other connections. So basically you just have to define a
connection, that has the edge's type as source and the node's type as
target. Now create a tool only for the connection (not for the node).
Finally, tweak you ModelingAssistantProvider so it will prompt you to
select a node type to create if a connection is drawn, not ending at an
existing target node. If only one target node type is possible the node
should be created even without prompting (although I'm not sure, maybe you
are also given the option to select some existing node).
What you get:
You can draw a connection A (the horizontal connection in figure 2) between
two nodes, and then draw a connection B (the vertical one) starting at
connection A and ending somewhere on the canvas, where then the node will
be created.
Hope this helps,
Tobias
Marsha wrote:
> Hi
>
> For my application I need to define a custom connection figure that looks
> like follows:
> 1) ******* 2) -------------->
> * * |
> ------* *-----> or *******
> * * * *
> ******* * *
> *******
>
> Id prefere the second one but the first one should do as well.
>
> Comments to the first one:
> There are two different possibilities. The first one is that the
> connection is defined as shown above and the rectangle is a compartment in
> order that oder elements can be placed in it. The second one is that the
> rectangle melts with the line as soon as placed on the connection.
>
> Comments to the second one:
> Here the idea is that first the line (connection) is drawn then the other
> figure (rectangle with the linking-line) can be hooked to the line.
>
> My problems for both ideas is that I don't know how to define a child
> element for the PolylineConnection.
> Is there a possibility to do this with the configuration files of GMF? Or
> do I have to write this extension on my own?
> If I have to write it on my own how do I have to do this, which classes
> need to be extended?
>
> Any hint is welcom, I'm looking for a solution for quite a long time
> already...
>
> Thanks a lot
> Marsha
|
|
| |
| Re: Custom connection figure [message #154784 is a reply to message #154687] |
Thu, 11 October 2007 03:52 |
| Eclipse User |
|
|
|
Originally posted by: tobk.gmx.de
Right, this part is a little tricky, and it can not be done via the
generator (although _sometimes_ everything is generated correctly, but in
most cases some manual coding is needed, so try, maybe it alrady works for
you).
(Besides, this part is optional. You can have the same result by just
creating tools both for the attachment-connection and the attachment-node.
However, in this case you will have to create the node first and then the
connection in a second step.)
In your XXX.diagram plugin there should be a class
XXXModelingAssistantProvider in the package XXX.diagram.providers. This
class determines what will be available in the various "modeling
assistants" (the little popup-palettes that appear when you hover the mouse
over some compartment as well as the little ingoing and outgoing arrows
that appear when you hover over a node).
The method names should be quite self-descriptive and each method returns a
list of element types that can be created. At least the method
getTypesForPopupBar should be implemented (although not necessarily very
optimal), so you can use this as a template. The method that's most
interesting in your case is getTypesForTarget. Here, you should check the
relationshiptype, and if it's the type of your attachment-connection (the
vertical one) you return a list holding only the type of the attached node.
This should be sufficient so you can draw an attachment-connection starting
at the regular connection and ending somewhere on the canvas (not at an
existing node), and a new node of that type should be created.
Maybe you should also modify selectExistingElementForTarget, so it returns
null (or an empty list, I'm not sure) for the attachment-connection-type.
Otherwise you might be prompted to select some existing attachment-node,
which wouldn't make much sense, I guess.
When everything is working you might also modify the remaining methods of
this class (all working in a similar manner), cause they are really helpful
for quickly drawing a diagram without having to return to the palette after
each element.
Hope this helps,
Tobias
Marsha wrote:
> tobias wrote:
>
>> I'm not sure about the first one, but the second one should go:
>
> As I prefer the second one anyhow this is exactely what I was looking for,
> thanks a lot for your help.
>
>> In GMF 2 (and with a little hacking in GMF 1, too) it is possible to
>> connect connections to other connections. So basically you just have to
>> define a connection, that has the edge's type as source and the node's
>> type as target. Now create a tool only for the connection (not for the
>> node).
>
> Up to here everything is fine and working.
>
>> Finally, tweak you ModelingAssistantProvider so it will prompt you to
>> select a node type to create if a connection is drawn, not ending at an
>> existing target node. If only one target node type is possible the node
>> should be created even without prompting (although I'm not sure, maybe
>> you are also given the option to select some existing node).
>
> For this part I don't really understand. Or better I see what you mean but
> I don't know how to achieve this...could you explain in more detail how
> this is done?
>
> Thanks
>
> Marsha
|
|
| |
| Re: Custom connection figure [message #154834 is a reply to message #154825] |
Thu, 11 October 2007 08:12 |
| Eclipse User |
|
|
|
Originally posted by: tobk.gmx.de
Hm, this is getting quite complicated...
Well, I have an idea, but I'm not sure if it's gonna work, and possibly it
will require some 'clever hacking' (aka bad style).
It is possible, to create contained elements on the same layer as their
parent, being connected to the parent with a link (tree-like) (I think the
correct term is "phantom nodes"). The trick is to define the child node's
mapping without specifying a containment feature and defining a link
mapping with target being the containment feature and the other field's
(except for Tool and DiagramLink, of course) being left blank.
Until now I have tried this only for other nodes being the parent, but since
the child element is created as a top node in the gmfmap this could work
for links, too.
So regarding the mapping definition there is no reason why it shouldn't
work, but of course it's possible that the developers of GMF did not regard
this case at that there will be some terrible exception during generation.
In this case you could try the same with some node and then "bend"
everything so it work's with the link.
Now I'm curious myself. I'll try it using the gmfmap only and report to you
if it works.
Tobias
Marsha wrote:
> Hi Tobias
>
> That is exactely what I want to do, but I think with my domain model this
> is not possible. (You can find my domain model at the end of this post.)
>
> The problem is that this domain model should be used and that the figure
> should look like described in the first post (preferably like figure 2).
> So the horizontal line should represent the PredecessorRelation EClass.
> The rectangle should represent the PredecessorConditionType EClass. That
> rectangle should be a compartment where the SimplePredecessorCondition
> and the HasResultPredecessorCondition can be added.
> The main problems are that the GAMEContext doesn't "know" the
> PredecessorconditionType because this doesn't make sence from the model
> point of view, but to be able to draw it on the canvas it should know it.
> The second big problem is that I don't have a representant on the model
> for the vertical connection.
> I'm asking it quite generally here, because I'm blocked on this problem.
> Maybe you have an other better idea I don't see to solve my representation
> problem.
>
> Or do I have to add the things I need but I don't want to represent in the
> domain model programmaticaly?
>
> Thanks for your help.
>
> Marsha
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="game"
> nsURI="http://www.swisscom.com" nsPrefix="game">
> <eClassifiers xsi:type="ecore:EClass" name="Step">
> <eStructuralFeatures xsi:type="ecore:EAttribute"
> name="autoAbortBehaviour" eType="#//AutoAbortBehaviour"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute"
> name="autoCancelBehaviour" eType="#//AutoCancelBehaviour"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"
> iD="true"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="isCompensation"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="type"
> eType="#//StepType"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="parameter"
> upperBound="-1"
> eType="#//StaticParameter" containment="true"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="implementation"
> upperBound="-1"
> eType="#//StepImplementation" containment="true"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="StepImplementation">
> <eStructuralFeatures xsi:type="ecore:EReference" name="cardinality"
> eType="#//StepCardinality"
> containment="true"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Activity"
> eSuperTypes="#//StepImplementation">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="function"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="version"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Flow"
> eSuperTypes="#//StepImplementation">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="version"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="StepCardinality">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="minInstances"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
> defaultValueLiteral="1"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="maxInstances"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
> defaultValueLiteral="1"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute"
> name="instantiationCondition"
> eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="StaticParameter"/>
> <eClassifiers xsi:type="ecore:EClass" name="PredecessorRelation">
> <eStructuralFeatures xsi:type="ecore:EReference" name="conditionType"
> eType="#//PredecessorConditionType"
> containment="true"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="predecessor"
> lowerBound="1"
> eType="#//Step"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="successor"
> upperBound="-1"
> eType="#//Step"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="SimplePredecessorCondition"
> eSuperTypes="#//PredecessorConditionType">
> <eStructuralFeatures xsi:type="ecore:EAttribute"
> name="fulfillCondition" eType="#//SimpleCondition"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute"
> name="cancelCondition" eType="#//SimpleCondition"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="abortCondition"
> eType="#//SimpleCondition"
> defaultValueLiteral=""/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="GAMEContext">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="aspectName"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EReference"
> name="predecessorRelation" upperBound="-1"
> eType="#//PredecessorRelation" containment="true"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="step"
> upperBound="-1" eType="#//Step"
> containment="true"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EEnum" name="SimpleCondition">
> <eLiterals name="complete"/>
> <eLiterals name="completeOrFailed" value="1"/>
> <eLiterals name="completeOrIgnoredError" value="2"/>
> <eLiterals name="error" value="3"/>
> <eLiterals name="exception" value="4"/>
> <eLiterals name="failed" value="5"/>
> <eLiterals name="started" value="6"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass"
> name="HasResultPredecessorCondition"
> eSuperTypes="#//PredecessorConditionType">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="resultName"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EEnum" name="AutoAbortBehaviour">
> <eLiterals name="toto"/>
> <eLiterals name="lulu" value="1"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EEnum" name="AutoCancelBehaviour">
> <eLiterals name="dummy"/>
> <eLiterals name="toto"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EEnum" name="StepType">
> <eLiterals name="manual"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="PredecessorConditionType"/>
> </ecore:EPackage>
|
|
|
| Re: Custom connection figure [message #154839 is a reply to message #154834] |
Thu, 11 October 2007 08:32 |
| Eclipse User |
|
|
|
Originally posted by: tobk.gmx.de
Wow, I can't believe this really worked! *g*
I'm sending you my test model via eMail...
Tobias
tobias wrote:
> Hm, this is getting quite complicated...
>
> Well, I have an idea, but I'm not sure if it's gonna work, and possibly it
> will require some 'clever hacking' (aka bad style).
>
> It is possible, to create contained elements on the same layer as their
> parent, being connected to the parent with a link (tree-like) (I think the
> correct term is "phantom nodes"). The trick is to define the child node's
> mapping without specifying a containment feature and defining a link
> mapping with target being the containment feature and the other field's
> (except for Tool and DiagramLink, of course) being left blank.
>
> Until now I have tried this only for other nodes being the parent, but
> since the child element is created as a top node in the gmfmap this could
> work for links, too.
>
> So regarding the mapping definition there is no reason why it shouldn't
> work, but of course it's possible that the developers of GMF did not
> regard this case at that there will be some terrible exception during
> generation. In this case you could try the same with some node and then
> "bend" everything so it work's with the link.
>
> Now I'm curious myself. I'll try it using the gmfmap only and report to
> you if it works.
>
> Tobias
>
>
> Marsha wrote:
>> Hi Tobias
>>
>> That is exactely what I want to do, but I think with my domain model this
>> is not possible. (You can find my domain model at the end of this post.)
>>
>> The problem is that this domain model should be used and that the figure
>> should look like described in the first post (preferably like figure 2).
>> So the horizontal line should represent the PredecessorRelation EClass.
>> The rectangle should represent the PredecessorConditionType EClass. That
>> rectangle should be a compartment where the SimplePredecessorCondition
>> and the HasResultPredecessorCondition can be added.
>> The main problems are that the GAMEContext doesn't "know" the
>> PredecessorconditionType because this doesn't make sence from the model
>> point of view, but to be able to draw it on the canvas it should know it.
>> The second big problem is that I don't have a representant on the model
>> for the vertical connection.
>> I'm asking it quite generally here, because I'm blocked on this problem.
>> Maybe you have an other better idea I don't see to solve my
>> representation problem.
>>
>> Or do I have to add the things I need but I don't want to represent in
>> the domain model programmaticaly?
>>
>> Thanks for your help.
>>
>> Marsha
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <ecore:EPackage xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="game"
>> nsURI="http://www.swisscom.com" nsPrefix="game">
>> <eClassifiers xsi:type="ecore:EClass" name="Step">
>> <eStructuralFeatures xsi:type="ecore:EAttribute"
>> name="autoAbortBehaviour" eType="#//AutoAbortBehaviour"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute"
>> name="autoCancelBehaviour" eType="#//AutoCancelBehaviour"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>> lowerBound="1" eType="ecore:EDataType
>> http://www.eclipse.org/emf/2002/Ecore#//EString"
>> iD="true"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute"
>> name="isCompensation"
>> eType="ecore:EDataType
>> http://www.eclipse.org/emf/2002/Ecore#//EBoolean"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="type"
>> eType="#//StepType"/>
>> <eStructuralFeatures xsi:type="ecore:EReference" name="parameter"
>> upperBound="-1"
>> eType="#//StaticParameter" containment="true"/>
>> <eStructuralFeatures xsi:type="ecore:EReference"
>> name="implementation"
>> upperBound="-1"
>> eType="#//StepImplementation" containment="true"/>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="StepImplementation">
>> <eStructuralFeatures xsi:type="ecore:EReference" name="cardinality"
>> eType="#//StepCardinality"
>> containment="true"/>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="Activity"
>> eSuperTypes="#//StepImplementation">
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="function"
>> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="version"
>> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"/>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="Flow"
>> eSuperTypes="#//StepImplementation">
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="version"
>> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"/>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="StepCardinality">
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="minInstances"
>> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
>> defaultValueLiteral="1"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="maxInstances"
>> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
>> defaultValueLiteral="1"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute"
>> name="instantiationCondition"
>> eType="ecore:EDataType
>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="StaticParameter"/>
>> <eClassifiers xsi:type="ecore:EClass" name="PredecessorRelation">
>> <eStructuralFeatures xsi:type="ecore:EReference" name="conditionType"
>> eType="#//PredecessorConditionType"
>> containment="true"/>
>> <eStructuralFeatures xsi:type="ecore:EReference" name="predecessor"
>> lowerBound="1"
>> eType="#//Step"/>
>> <eStructuralFeatures xsi:type="ecore:EReference" name="successor"
>> upperBound="-1"
>> eType="#//Step"/>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="SimplePredecessorCondition"
>> eSuperTypes="#//PredecessorConditionType">
>> <eStructuralFeatures xsi:type="ecore:EAttribute"
>> name="fulfillCondition" eType="#//SimpleCondition"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute"
>> name="cancelCondition" eType="#//SimpleCondition"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute"
>> name="abortCondition"
>> eType="#//SimpleCondition"
>> defaultValueLiteral=""/>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="GAMEContext">
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="aspectName"
>> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> <eStructuralFeatures xsi:type="ecore:EReference"
>> name="predecessorRelation" upperBound="-1"
>> eType="#//PredecessorRelation" containment="true"/>
>> <eStructuralFeatures xsi:type="ecore:EReference" name="step"
>> upperBound="-1" eType="#//Step"
>> containment="true"/>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EEnum" name="SimpleCondition">
>> <eLiterals name="complete"/>
>> <eLiterals name="completeOrFailed" value="1"/>
>> <eLiterals name="completeOrIgnoredError" value="2"/>
>> <eLiterals name="error" value="3"/>
>> <eLiterals name="exception" value="4"/>
>> <eLiterals name="failed" value="5"/>
>> <eLiterals name="started" value="6"/>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass"
>> name="HasResultPredecessorCondition"
>> eSuperTypes="#//PredecessorConditionType">
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="resultName"
>> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EEnum" name="AutoAbortBehaviour">
>> <eLiterals name="toto"/>
>> <eLiterals name="lulu" value="1"/>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EEnum" name="AutoCancelBehaviour">
>> <eLiterals name="dummy"/>
>> <eLiterals name="toto"/>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EEnum" name="StepType">
>> <eLiterals name="manual"/>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="PredecessorConditionType"/>
>> </ecore:EPackage>
|
|
|
| Re: Custom connection figure [message #154846 is a reply to message #154834] |
Thu, 11 October 2007 08:34 |
| Eclipse User |
|
|
|
Originally posted by: marsha.rohrer.swisscom.com
> Hm, this is getting quite complicated...
Yes I know...I'm trying to get that fixed some days already.
> Well, I have an idea, but I'm not sure if it's gonna work, and possibly it
> will require some 'clever hacking' (aka bad style).
So in your opinion it would be better to adapt the domain model?
Or maybe another solution, do you know if I can define a figure that
contains the rectangle with the vertical connection already on it (which
will represent the PredecessorConditionType EClass a problem I see here is
to get the rectangle act as a compartment...), so I have only to link the
connection to the according PredecessorRelation...
|
|
|
Goto Forum:
Current Time: Tue Jul 22 15:50:01 EDT 2025
Powered by FUDForum. Page generated in 0.04197 seconds |
Home