The latest changes that were authored resulted in a defect. If an edge pointer Visibility happens to be set by either a Binding or Converter, then the original code was overwriting the Visibility property value.
* Update GraphArea.cs
Have noticed that sometimes during DeSerialization a failure for Source or Target to be updated properly will result in an uncaught exception to the Application Dispatcher. It is best to test for a valid Source and Target Property value before attempting to retrieve a mapped value.
* Update GraphArea.cs
Testing revealed an issue.
When the property IsDragSelectByDefault is set to true and the user clicks on the zoom area, the ZoomBox is being set to empty and this breaks bindings resulting in the Canvas/Border 2x2 element to actually be rendered as an annoying random pixel in the upper left corder of the Zoom control.
* Bugfix: Must take polymorphic controls into consideration.
* Bugfix: Must save original position of all tagged controls, regardless of the primary drag vertex status.
Before the fix, it was possible to get out of sync with the "IsTagged" status of the primary drag vertex (it was set after the drag start). When that happened, the secondary vertices being dragged, did not have its OriginalX/Y properties updated, resulting in a "jump" from its visual origin to X=0, Y=0.
* Bugfix: compare with argument, not default initialized field.
* Bugfix: Must take polymorphic controls into consideration.
* Bugfix: Must save original position of all tagged controls, regardless of the primary drag vertex status.
Before the fix, it was possible to get out of sync with the "IsTagged" status of the primary drag vertex (it was set after the drag start). When that happened, the secondary vertices being dragged, did not have its OriginalX/Y properties updated, resulting in a "jump" from its visual origin to X=0, Y=0.
* Modified the grouping mechanism used for parallel edges. This is in preparation for some other changes related to the way edges with connection points are handled. These code changes will alter the sequence of edges and does not attempt to preserve the exact ordering of the old code. In the old code, the groups were built simply as the edges were encountered and did not appear to have a defined order, so I think this should be fine, but it could change the appearance of existing graphs. The new code also excludes edges that have both ends tied to connection points because those will not be spaced within the group anyway. There is a small performance penalty for very small numbers of edges, but at 50-100 edges a 3-10x speed improvement can be observed.
* Modified the parallel edge logic so that it takes connection points into account. If an edge uses a connection point at only one end and parallel line grouping is in effect, the edge will be rendered parallel, but aligned to the connection point.
* Restored the use of parallel edge groups with just one edge. This way, parallel edge behavior is applied to single edges with one connection point.
* Edge Drag (#75)
* + SetEdgesDrag
* + Edge가 Drag 가능하도록 설정
* + Edge Drag
* Fix
* + PrepareEdgePathFromMousePointer Target Position Edit
Virgile Bello
panthernet
bleibold
George Birbilis
RachelTerry
jorgensigvardsson
Jon
LaborJos
Virgile Bello
Edgardo Zoppi
galakt