[Scilab-users] question on graphic children order
Stéphane Mottelet
stephane.mottelet at utc.fr
Mon Apr 8 23:01:29 CEST 2019
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>
>>>
>>>
>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at lists.scilab.org
>>> https://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
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20190408/7cc2c02f/attachment.htm>
More information about the users
mailing list