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

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

[Octave-bug-tracker] [bug #52621] root graphics object property "current


From: Rik
Subject: [Octave-bug-tracker] [bug #52621] root graphics object property "currentfigure" does not respect figure "handlevisibility" property
Date: Mon, 11 Dec 2017 12:23:32 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Update of bug #52621 (project octave):

                  Status:         Patch Submitted => Patch Reviewed         
                 Release:                   4.2.1 => dev                    

    _______________________________________________________

Follow-up Comment #7:

@Pantxo: Good work.  I checked in the patch here
http://hg.savannah.gnu.org/hgweb/octave/rev/41cf6ee90cb6.

This is enough of a change that odd side effects are likely to crop up for a
while.  For example, I tried this.


octave:2> h1 = figure
h1 =  1
octave:3> h2 = figure
h2 =  2
octave:4> set (h1, 'handlevisibility', 'off')
octave:5> close all   # At this point, h2 was closed
octave:6> close all hidden
warning: closereq: calling closereq from octave prompt is not supported, use
'close' instead
warning: called from
    closereq at line 38 column 5
    close at line 99 column 3


The problem is in closereq.m



  cf = gcbf ();
  if (isempty (cf))
    warning ("closereq: calling closereq from octave prompt is not supported,
use 'close' instead");
    cf = get (0, "currentfigure");
  endif


The file closereq.m is trying to use gcbf to see whether a callback is
executing.  It seems like either we could get rid of the warning (which still
wouldn't work for hidden figures), we could modify close.m to reset the
handlevisibility property of all objects that it is about to call the
closerequestfcn, or we have to invent something in C++ graphics code that
allows gcbf to show through for figures which are being deleted (maybe when
the "beingdeleted" property is true?).

I looked through the m-files for gco, gcbo, gcbf instances which might cause
problems.  The only ones that looked like they might be an issue were these
from gcbf


gui/dialog.m:100:    "buttondownfcn", "if isempty (allchild (gcbf)), close
(gcbf), endif",
plot/appearance/legend.m:1116:        && (isempty (gcbf ()) || strcmp (get
(gcbf (), "beingdeleted"),"off"))
plot/appearance/legend.m:1136:      && (isempty (gcbf ()) || strcmp (get (gcbf
(), "beingdeleted"), "off"))
plot/appearance/legend.m:1146:        && (isempty (gcbf ()) || strcmp (get
(gcbf (), "beingdeleted"), "off"))
plot/draw/colorbar.m:262:      && (isempty (gcbf ()) || strcmp (get (gcbf (),
"beingdeleted"), "off")))
plot/draw/colorbar.m:312:      && (isempty (gcbf ()) || strcmp (get (gcbf (),
"beingdeleted"), "off")))
plot/draw/colorbar.m:335:      && (isempty (gcbf ()) || strcmp (get (gcbf (),
"beingdeleted"), "off")))
plot/draw/colorbar.m:354:      && (isempty (gcbf ()) || strcmp (get (gcbf (),
"beingdeleted"),"off")))
plot/draw/plotyy.m:207:      && (isempty (gcbf ()) || strcmp (get (gcbf (),
"beingdeleted"), "off"))
plot/util/closereq.m:36:  cf = gcbf ();
plot/util/private/__add_default_menu__.m:89:    set (gcbf, "filename",
fname);


I haven't reviewed any of the other instances besides closereq.m which I
stumbled upon. 


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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