[Top][All Lists]

[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: Tue, 12 Dec 2017 21:31:52 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

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);
      legend (legdata.handle, hplots, text_strings);

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

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

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:


  Message sent via/by Savannah

reply via email to

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