octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #52641] Changing legend "displayname" property


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #52641] Changing legend "displayname" property to empty string "" leads to printing an error
Date: Mon, 11 Dec 2017 23:23:46 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Follow-up Comment #4, bug #52641 (project octave):

The source of the original error is this hunk of code

get (hplots(1), "parent")

either in and of itself or because it generates something that is not a valid
handle.  But we know the legend handle already, so I changed that conditional
test to:


%    if (! isempty (hplots))
      legend (hlegend, hplots, text_strings);
%    endif


But this produces a warning/error:


warning: legend: plot data is empty; setting key labels has no effect
warning: called from
    legend at line 378 column 9
    legend>updateline at line 1193 column 7
error: legend: expecting argument to be a string


There is an inherent issue here in the fact that the legend name objects have
disappeared without having cleared or redrawn the "Legend String" contents. 
Since there is nothing to be redrawn, the plot graphics don't change.

Either the legend needs to retain some form of string (an emtpy string "")
that will be redrawn, or the legend code needs to know that if the name
strings are empty that a clear needs to be done.  It doesn't seem logical, as
far as the latter case.  Somewhere when the "displayname" is run it needs to
recognize the legend name is changing so it has to redraw, regardless of the
empty string.

Perhaps gnuplot has it right somehow in that regard, but I don't think
intentionally.  Hmm, it seems to me the underlying problem is that there are
two locations containing the same information.  Note that after the error
above, I look at the contents:


octave:20> get(h,'displayname')
ans =
{
  [1,1] = 
  [2,1] = 
}

octave:21> kids = get(gcf,'children')
kids =

  -10.640
  -15.349

octave:23> get(kids(1),'string')
ans =
{
  [1,1] = First Line
  [1,2] = Second Line
}


There is a circular problem here.  If one changes the figure "displayname",
that has to trigger a change in the legend's "string".  If one changes the
legend, that has to trigger a change to the figure's "displayname".  And if
there is a redraw in both locations, it complicates matters.  If this
information were contained in only one location, perhaps it would make it more
tractable.  I'll think about this a bit.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52641>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]