I found all nodes have the same zOrder and increase or decrease the zOrder same time the nodes do not stack correctly. stack order is change, don’t keep original order.
by the way, convenient to explain I grouped all nodes into one group.
You can stack all nodes together and select all, then change the zorder will get the same result.
I used this https://gojs.net/latest/extensionsTS/DrawCommandHandler.html for test
If two nodes have the same Part.zOrder value, their actual ordering is indeterminate. It probably just matters what the Array.sort function does.
When two nodes have the same Part.zOrder, I think it is important to stack according to the order that they were added to the diagram order. If not, when we are editing the diagram, the order is unstable and looks weird.
I think there are several ways of achieving what I think you are asking for. You are welcome to modify/adapt the pushToBack and pullToFront code in extensionsTS/DrawCommandHandler.js/ts to meet your requirements.
I am not asking for the pushToBack and pullToFront have a problem, they do all good jobs, include when objects in the groups.
This is the diagram behaver, If I reimplement those pull front or send back method, it also faces the same z-index problem.
I suggest that you make sure that the Part.zOrder values, when they are numbers, are unique.
But you know manage up a unique z-index is hard work, if the diagram has thousands of nodes, when chang one node’s z-index it must babble out all other nodes z-index. increment JSON got bigger, not efficient.
maybe have a most good solution, but right now I did not figure any good solutions
Yes, that is a problem, and it has multiple solutions depending on the specific app’s requirements.
That is why the default behavior has always been to leave the actual ordering unspecified, but allow apps to control it if they want.
Note that there is one bit of ordering that GoJS always does by default – a Group is always behind each of its members if both are in the same Layer.
The diagram has default order, not ordering unspecified, if it totaly unspecified that fine we developer make own order. At the beginning it ordering added order. append later will gos on top.
that is correct, all other software dose same thing like ms-office exp. reload JSON from server it keep the order perfect.
but set z-index higher number or lower number on multiple nodes it not keep this manner.
reload JSON from server it came back to default order. please check it deeply.
Yes, you get the default ordering within a layer if the Part has a NaN zOrder. If the Part has a real numeric zOrder, then that governs its relative z-ordering compared with other Parts that have numeric zOrder.
On the other hand, if it is the problem of the extension like pushToBack and pullToFront
I will write my own function, it no problem.
But it also occurs I select multiple nodes, and set zindex to pull to the front or send it back.
but after reloading the JSON from the server it changes the order.
I want say that when nodes has same Number it not keep the default order. when editing !! .
some times it ordering reversely. but reload from server again it came back to appending order.
here is the test code.
select all and push 「ー」button. it will order reversely. it changes the default order.
I think the behavior is happening because some code is iterating through some collection of nodes, in a particular order, assigning the Part.zOrder. As each assignment is made, the node is “moved” in the Layer.parts list’s sequence. As the node is “moved” in the list, it is only moved the minimal amount in order to satisfy the requirement imposed by the value of the Part.zOrder.
Imagine these nodes sorted by zOrder in the layer’s parts list:
So when moving the lightblue and orange nodes forward (i.e. more in front, or at higher indexes in the list, here shown towards the right), let’s say we move the lightblue node first by setting its zOrder to 7:
Then we move the orange node by setting its zOrder to 7:
The minimal move within the list is what is causing the changed paint order. But officially that is OK because GoJS does not guarantee the ordering of parts with the same value.
Parts that have zOrder that is NaN aren’t rearranged in the layer’s parts list, so they don’t happen to change apparent paint order until you remove them from the layer and then put them back in again.
I begin to understand the zOrdering system, maybe it not a huge and complicated one, but quite a simple principle.
If then I can control the iterating order to control the z-ordering swap. I will test it carefully. and report it later.
hope gojs not change this behaver, if any change happens will break my code. this is important.
Well, we have no intentions of changing the implementation, but it’s not something that we can guarantee forever. After all, that’s exactly why there are a number of situations where the behavior is indeterminate – to give us flexibility for performance or whatever. One of those whatevers had been the behavior of Array.sort, in fact, which had been different on Chrome than in other browsers.
I make all zOrder works good, I did not use Array.sort , just when I set the zOrder reorder the selection nodes to the same as the original node array order. this time a bit difficult is to order group zOrder. but I did it, thank you walter.