[Scilab-users] xpoly()

[Stefan Du Rietz]

On 2014-11-20 12:59, Antoine Monmayrant wrote:
> On 11/19/2014 06:39 PM, Stefan Du Rietz wrote:
>> Hello,
>>
>> I have made quite an effort to write commands in numerous sci-files
>> with the low level function xpoly() to avoid changes to the axes.
>>
>> But (surprise, surprise!), suddenly the low level function make
>> those changes, and there is no way of avoiding it!
>>
>> Because set(a,"auto_clear","off") only works for high level functions:
>>
>> auto_clear:
>> "If this property value is equal to "on", a call to a high level
>> graphic will re-ininitialize the current axes and erase all its
>> children before preforming the drawing (log_flags will be reset). If
>> the value is "off" the drawings will be added to current axes
>> according to "auto_scale" property."
>>
>> So, the good low level function has become a new type of high level
>> function (that does not obey the usual rules) and is not replaced by
>> anything!
>>
>> Is that not a serious bug?
> Hi,
>
> It sounds like a regression.
> You might be able to hack a workaround by making your own version of
> xpoly that correct the changes?
> Something like:
>
> //horrible pseudo code
> your_xpoly(poly_arguments):
>      //keep a copy of the axis properties before
>      //calling xpoly
>      a=gca();
>      ac=copy(a);
>
>      //actual call to xpoly
>      x=sin(2*%pi*(0:4)/5);
>      y=cos(2*%pi*(0:4)/5);
>      xpoly(x,y,"lines");
>
>      //undoing xpoly changes to the axis
>      a.data_bounds=ac.data_bounds;
>              ...
>      a.whatever=ac.whatever;
>
>      //clean up the mess
>      delete(ac);
> end
>
>
> Antoine
>
>
Thanks, Antoine, but to be on the safe side I will have to include 
*all* the axes properties and I will have a large script instead of a 
built-in function with the advantages of speed etc.:

-->typeof(xpoly)
  ans  =
  fptr

Stefan