Le 10/04/2019 à 01:24, Federico Miyara a écrit :
Antoine,
Thank you for your suggestion. It's a good one, but I still don't know
the reason why the index of the current entity is 1 (my question was
not really about workarounds but reasons). Stéphane said it was a
stack, but as far as I could find, there is no stack structure in
Scilab 6.
It was an image. The graphics objects tree is not built at the
interpreter level but internally with, at the end, Java objects. In
modules/graphic_objects/src/java/org/scilab/modules/graphic_objects/graphicObject/GraphicObject.java
you can see that the set of children of a graphic object is a (Java) list
/** Child objects list. Known by their UID */
private List <Integer> children;
When a children is added to a graphic object, the the method "addChild"
is invoked. In the source you can see
public void addChild(Integer child) {
children.add(0, child);
}
Which is coherent with the actual behavior i.e. news children are pushed
on the top.
What you would like is simply (without the 0)
public void addChild(Integer child) {
children.add(child);
}
If I have time I can see if it breaks other things, but I am almost sure
that it will...
S.
On 09/04/2019 04:22, Antoine Monmayrant wrote:
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.motte...@utc.fr <mailto:stephane.motte...@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/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/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@lists.scilab.org <mailto:users@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/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users>
_______________________________________________
users mailing list
users@lists.scilab.org <mailto:users@lists.scilab.org>
http://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@lists.scilab.org <mailto:users@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@lists.scilab.org <mailto:users@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@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.monmayr...@laas.fr
permanent email :antoine.monmayr...@polytechnique.org
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
