[Octave-bug-tracker] [bug #52641] Changing legend "displayname" property to empty string "" leads to printing an error

[Dan Sebald]

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

OK, then rather than UserData, this legend code could have used some other
name and made it private.  Not that important.

However, I'm still wondering about this solution.  In the years I've been
programming and as frameworks have evolved, I've grown to not like setting
some variable on/off in anticipation of some loopback mode.  Often some bug
shows up that is a strange combination of circumstances.

It seems to me the major issue here is that updateline() calls legend() rather
than something more straightforward, i.e.,


    [hplots, text_strings] = __getlegenddata__ (hlegend);
    if (isempty (hplots))
      delete (hlegend);
    else
      legend (legdata.handle, hplots, text_strings);
    endif


which in turn recursively sets the parents' "displayname" in the legend() main
function:


          if (have_labels)
            set (kids(k), "displayname", arg);
          endif


Therein lies the problem.  There is no need for updateline() to eventually set
some "displayname" because updateline is a callback originating from one of
the parent plot objects, correct?  It's not the legend() initiating
updateline(), it is the parent.  Furthermore, if updateline() was
called--being a callback from some existing object--the only thing that can
happen is that "displayname" is updated for the text-object (indicated by the
passed-in handle via the listener) or it is empty in which case that means
simply deleting the associated legend objects from the list.  We could in fact
pass both the line (surface, patch) icon handle and the text handle via the
listener.  So, is there ever a case where an updateline() needs to completely
reconstruct the legend by calling legend()?  If so, we could still keep the
construction as a separate routine and have only the setting of parent
"displayname"s in the true legend() subroutine.

    _______________________________________________________

Reply to this item at:

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

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