[Scilab-users] question on graphic children order

[P M]

Federico...thanks for asking the question.
I was wondering about it myself for quite some time.
Once recognizing the fact, I just accepted that new entities are placed at
the first position.
However, it might be interesting to get some insight of why it is like
this....for now I guessed it has to do with how to handle memory.

Philipp


Am Mo., 8. Apr. 2019 um 23:01 Uhr schrieb Stéphane Mottelet <
stephane.mottelet at utc.fr>:

> Le 08/04/2019 à 22:56, Federico Miyara a écrit :
>
>
> Stéphane,
>
> Sometimes one just needs to extract some parameter from an entity and
> indexing is a valid way to access it.
>
> So what is your problem since you know that the order of entities is,
> though not natural, reproductible ? If you really need to recover a deeply
> hidden entity, use tags and the findobj() function.
>
> S.
>
>
> Federico
>
>
> On 08/04/2019 12:18, Stéphane Mottelet wrote:
>
> Hello,
> Le 07/04/2019 à 10:13, Federico Miyara a écrit :
>
>
> Dear all,
>
> I would like to know if there is a reason for the fact that whenever new
> graphic objects are added to an axes, the last one that has been created is
> always the one with index 1 instead of n+1 (where n is the number of
> objects prior to new one).
>
> Example:
>
> scf(1)
> clf(1)
>
> // Plot a simple two-point graph
> plot2d([0, 1], [0, 1])
> ax = gca()
>
> // Colect plotted data
> a = ax.children(1).children.data
>
> // Plot a simple two-point graph
> plot2d([0, 1],[0.5, 1.5])
>
> // Colect plotted data corresponding to index 1
> b = ax.children(1).children.data
>
> // Colect plotted data corresponding to index 2
> c = ax.children(2).children.data
>
> After the first plot we get
>
> a  =
>    0.   0.
>    1.   1.
>
> After the second plot we get
>
> b  =
>    0.   0.5
>    1.   1.5
>
> c  =
>
>    0.   0.
>    1.   1.
>
> I would expect that b = a, i.e, once a children object has been created on
> the axes, it would be reasonable that its index were kept constant. The
> current behavior is as if each new object were inserted in the structure
> before the previous one instead of after it.
>
> I would say that the set of children is a stack, i.e. each new child is
> "pushed" on top. Anyway, relying on child order seems, to me, a bad idea.
> For example, legend takes as (optional) first argument an array of handles,
> and not an array of child numbers.
>
> S.
>
>
> Regards,
>
> Federico Miyara
>
>
>
> <https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Libre
> de virus. www.avast.com
> <https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> <#m_-570024488477070350_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> _______________________________________________
> users mailing listusers at lists.scilab.orghttps://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users <https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users>
>
>
>
> _______________________________________________
> users mailing listusers at lists.scilab.orghttp://lists.scilab.org/mailman/listinfo/users <https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users>
>
>
>
> _______________________________________________
> users mailing listusers at lists.scilab.orghttps://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20190409/877dd76c/attachment.htm>