Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 507274

Summary:	The bordered node created by a tool are not placed near the mouse cursor in the container in some context
Product:	[Modeling] Sirius	Reporter:	Pierre Guilet <pierre.guilet>
Component:	Diagram	Assignee:	Maxime Porhel <maxime.porhel>
Status:	CLOSED INVALID	QA Contact:
Severity:	normal
Priority:	P3	CC:	laurent.redor, maxime.porhel
Version:	4.1.0	Keywords:	triaged
Target Milestone:	---
Hardware:	PC
OS:	Windows NT
Whiteboard:

Description Pierre Guilet

2016-11-09 04:48:03 EST

In a diagram of a design I did, I have a container with bordered nodes and a creation tool adding border nodes to the container.

When I use this tool, the nodes are added next to the other from a fix point in the container without taking in consideration the mouse cursor position.

I can't provide my design and example and I did not manage to reproduce the problem with a simple example.

So I don't know how to reproduce the problem.

Comment 1 Laurent Redor

2016-11-10 03:41:24 EST

Can you try to reproduce with the sample from /org.eclipse.sirius.tests.junit/data/unit/dragndrop/VP-3894 ? I dit not reproduce the problem.

Have you the "snap to grid" enabled with a "big" grid spacing? In this case, new border nodes are snap to the grid and it is expected.

Comment 2 Pierre Guilet

2016-11-10 04:13:21 EST

I tried with and without and the result is the same.

Comment 3 Laurent Redor

2016-11-10 05:38:06 EST

The sample of comment 1 works. So without reproduction case, we can not investigate.

Comment 4 Pierre Guilet

2016-11-17 07:34:42 EST

The problem is the following :
When adding the bordered node, during the creation process :
 - First, a LayoutData is created for the part target of the creation tool by mouse click with information about the click position. 
 - Then, this LayoutData is flushed from the SiriusLayoutDataManagerImpl whereas it should not to work correctly. 
 - The reason why it flushes is that the created bordered node has a conditional style that points at a service for its activation computation. This service changes an attribute value of the new created semantic element with     session.getTransactionalEditingDomain().getCommandStack().execute(updateCommand); This call created an OperationHistoryEvent that is detected by SiriusLayoutDataFlusher that runs the flushing.
 - Then the method using the LayoutData to compute the constraint used to position the new created element in the diagram is done but because of the flush, it is not used and default positioning is used.


Conclusion I will modify my service so it will not change the value of the attribute during its creation time.

Comment 5 Pierre Guilet

2016-11-17 07:52:44 EST

But maybe the flushing condition is not precise enought?

Comment 6 Maxime Porhel

2017-04-20 09:23:07 EDT

Hi Pierre, 

It seems that you service executes a command on the command stack. But the evaluation of your expression calling your service by Sirius is already done in a command. So you can directly modify your model without the use of the command. You will avoid to create an OperationHistoryEvent and this will not flush the layout data.

I close this issue as invalid as it really seems to come from your service. Do not hesitate to reopen the bugzilla if the proposed solution does not solve your issue.

Regards, 

Maxime