[Scilab-users] question on graphic children order

[Antoine Monmayrant]

Hello,

As Stéphane said, using a tag and findobj is a possibility that I use 
for complex layouts.
Here is another one: build your own vector of handles that you order the 
way you want:

as=[];
subplot(221)
plot(1,2)
as=[as,gca()]
subplot(222)
plot(1:2,2:3)
as=[as,gca()]
subplot(223)
plot(2*[1:2],2:3)
as=[as,gca()]
subplot(224)
plot(2*[1:2],-[2:3])
as=[as,gca()]
as.foreground=color('gray');
as.background=color('lightgray');
as.thickness=2;
as.font_size=4;

Cheers,

Antoine

Le 09/04/2019 à 08:30, P M a écrit :
> 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 <mailto: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 list
>>>>     users at lists.scilab.org  <mailto:users at lists.scilab.org>
>>>>     https://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 list
>>>     users at lists.scilab.org  <mailto:users at lists.scilab.org>
>>>     http://lists.scilab.org/mailman/listinfo/users  <https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users>
>>
>>
>>     _______________________________________________
>>     users mailing list
>>     users at lists.scilab.org  <mailto: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 <mailto:users at lists.scilab.org>
>     http://lists.scilab.org/mailman/listinfo/users
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users


-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

  Antoine Monmayrant LAAS - CNRS
  7 avenue du Colonel Roche
  BP 54200
  31031 TOULOUSE Cedex 4
  FRANCE

  Tel:+33 5 61 33 64 59
  
  email : antoine.monmayrant at laas.fr
  permanent email : antoine.monmayrant at polytechnique.org

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20190409/89bc8aa1/attachment.htm>