Community
Participate
Working Groups
It is quite hard to add a port *on the border* of a block in BDDs. The pb is that the port creation seems to be intercepted by the block compartments, unless the port is created right on the border line of the block or on the block header. If the compartment allows for ports (like the "properties" compartment), then unless the user clicked exactly on the border, the port will be added as a new item in the compartment and not as a new symbol on the border of the block. It would be much easier if there was a kind of virtual margin around the border that would not be intercepted by the nested compartments. Moreover, when the user does manage to target the border line, the port's graphical symbol is not added where the user clicked, but always on the top-left of the block rectangle. And if several ports are added, they are all put on top of each others.
Created attachment 200921 [details] patch to fix the bug patch to fix the bug
I send you a proposition to fix the bug.
(In reply to comment #0) > Moreover, when the user does manage to target the border line, the port's > graphical symbol is not added where the user clicked, but always on the top-left > of the block rectangle. And if several ports are added, they are all put on top > of each others. Addressed in Bug#352350.
(In reply to comment #2) > I send you a proposition to fix the bug. Thanks Patrick, your patch will save me a lot of time. Just need to fix precise positioning in the related CreationEditPolicy / Locator and it should work without trouble.
(In reply to comment #4) > (In reply to comment #2) > > I send you a proposition to fix the bug. Problems with this solution: - it modifies all existing diagram appearance as the stored Block size and location is related to the BorderedContainerFigure and the visible Block figure is reduced in this rectangle. - it has a strange behavior (from a user point of view) which is that the Block is not (visually) created where and with the size given by the user (I mean the BorderContainerFigure is correct but its invisible for users).
Created attachment 200996 [details] Alternate patch Solution trying to avoid any change in current figure location computation.
(In reply to comment #2) > I send you a proposition to fix the bug. Patrick, maybe we can manage this issue simply by modifying figure detection in "findFigureAt()" method. This implementation normally look for the figure in the borderItemContainerFigure first, then in the main figure, I propose (in case the previous search fails) to also look if the given position is located in a Rectangle larger than the MainFigure. This should be enough to activate the correct edit part. Can you review and test this patch ?
https://bugs.eclipse.org/bugs/attachment.cgi?id=200996 applied. r5203 in 0.8.x r5204 in trunk.
(In reply to comment #8) Slight modification, the selection area is dispatched on each side of the figure border (in and out). > r5211 in 0.8.x > r5212 in trunk.
(In reply to comment #9) The selectable area around figure would require deeper modification to support the case were the figure in located inside a compartment, only the inside area is kept: r5221 in 0.8.x r5222 in trunk.
