I have an issues to get avoid nodes working within a group for non-internal links. Links that go from the port of the group node to a port of a node that is member of the group do not avoid the nodes of the group. (Links between nodes of the group work correctly).
Any idea how to achieve this?
Here is an example where it goes wrong:
While I was hoping to get the following layout (made by hand):
Try using an alpha build. Before 1.5 we were inconsistent regarding whether a Link connecting a Group with a Node inside the Group was considered a member of the group or not. For 1.5 we are changing it to be more consistent with what you are expecting. Since this kind of change is both a bug fix and an incompatible change, it’s not something I feel comfortable putting into the 1.4 stream.
Tell us if 1.5 alpha helps your case, or if you encounter any other problems. We’re still getting 1.5 ready for beta, so it will be a while before it’s generally “ready”. Sorry, but we can’t plan that far ahead.
Also, what Layout does your Group.layout use?
Thanks for the quick response. I tried 1.5 alpha; I do not see a difference. The layout I am using is TreeLayout.
I hope the initial animation can be disabled?
Yes, set Diagram.animationManager.isEnabled to false. Examples of this include http://gojs.net/latest/samples/dataVisualization.html and http://gojs.net/latest/samples/virtualizedTree.html
I’ll try to implement your sample in 1.5 alpha.
OK, here’s a sample that works in version 1.4. (There’s a bug in 1.5 alpha, but you don’t need to use 1.5 alpha yet.) First, the screenshot:
[code]<!doctype html>Basic GoJS Sample
Also you might be interested in a similar but differently structured sample: http://gojs.net/latest/extensions/Parallel.html . It too works in version 1.4. Here’s a screenshot:
Thanks for the example and its code. I compared it to my code and I think it follows the same pattern (including “avoidable” set to false on the group). However, there are some differences: the ports are defined by an itemArray but I do not think that’s an issue. The other thing is that the nodes inside the outer group are groups again; this allows nested diagrams.
Any though why my code is not working?
Hmm, sorry, but I can’t think of any obvious reason at this moment.
Perhaps it would help if you set the Group.layout’s TreeLayout.arrangement = go.TreeLayout.ArrangementHorizontal.
I had a more indept look what it the difference between my code (with the issue) and the code of the example. Turns out their is none: the code of the example has also the issue that links from/to the edge of the group are not treated as “avoidsnodes”.
This is visible if you move the nodes yourself, or if you change the direction of the TreeLayout to vertical then already the initial layout has the same issue:
Psi is the original initial TreeLayout layout: the edge from zeta to the righthand side external port is routed through eta. For Omega I moved around the nodes themselves and then you also see the issue.
Could you provide me with a workaround or another way in order to avoid this issue?
Which version of GoJS are you using?
Ah, you’re right – that case is only fixed in version 1.5. We should be producing another pre-release build of 1.5 soon, maybe tomorrow, if you want to try it then.
I have changed the templates so that everything is vertically oriented, and I added a nested group. Here’s the new results:
The new code also uses a smarter link template so two separate link templates are no longer necessary, as you can see in the model data.
[code]<!doctype html>Basic GoJS Sample
Do you have any indication when 1.5 will be official available? (And, how do I get a pre-release?).
No, I don’t know when we officially release 1.5.0 as the “latest” version – we’re still working on a few things before we can start “beta”.
But in the meantime, you can experiment with it at http://gojs.net/alpha. I just built and uploaded a snapshot of what we have at this moment. I just built it, so we haven’t yet had a chance to do all of our platform testing. You won’t be able to download custom libraries, since we don’t do that for alpha versions.
In the mean time, there is no easy work around available?
Not in version 1.4. As I said before, above, this involves a bug fix which could break a (very) few existing apps, so I did not want to unnecessarily disturb anyone by putting those changes in the version 1.4.* stream.