plotyy handle problems ( was Re: [changeset] - bug and fix for surfnorm() )

[Ben Abbott]

On Oct 20, 2008, at 9:39 PM, Ben Abbott wrote:

>
> On Oct 20, 2008, at 11:40 AM, John W. Eaton wrote:
>
>> On 20-Oct-2008, David Bateman wrote:
>>
>> | John W. Eaton wrote:
>> | > On 20-Oct-2008, Ben Abbott wrote:
>> | >
>> | > | The reason I was concerned about the old state was for a
>> special case
>> | > | where oldh==h and an error occurred after "hold on". In such
>> an event,
>> | > | I thought it appropriate to restore oldh to its original hold
>> state.
>> | > |
>> | > | Does that make sense, or have I missed something that makes
>> such an
>> | > | event impossible?
>> | >
>> | > I think that is handled by my change because the code in the
>> | > undwind_protect_cleanup block is always executed.
>> | >
>> | >
>> | >
>> |
>> | I added a couple of other changesets after this, and we appear to
>> get
>> | through all of the tests with rundemos, except occasionally
>> "quiver3"
>> | appears to fail with an invalid handle.. Don't understand this one
>> yet..
>>
>> Starting a fresh Octave session and doing
>>
>> demo quiver3
>> demo quiver3
>> ...
>>
>> seems to work fine for me.  However, starting a fresh session and
>> running
>>
>> demo plotyy
>> demo quiver3
>>
>> seems to fail each time.
>>
>> jwe
>
> In plotyy I see the subfunction ...
>
> 193 function deleteplotyy (h, d, ax2, t2)
> 194   if (ishandle (ax2) && strcmp (get (ax2, "type"), "axes") &&
> 195       (isempty (gcbf()) || strcmp (get (gcbf(),
> "beingdeleted"),"off")) &&
> 196       strcmp (get (ax2, "beingdeleted"), "off"))
> 197     set (t2, "deletefcn", []);
> 198     delete (ax2);
> 199   endif
> 200 endfunction
>
> Shouldn't this be
>
> 193 function deleteplotyy (ax2, t2)
> 194   if (ishandle (ax2) && strcmp (get (ax2, "type"), "axes") &&
> 195       (isempty (gcbf()) || strcmp (get (gcbf(),
> "beingdeleted"),"off")) &&
> 196       strcmp (get (ax2, "beingdeleted"), "off"))
> 197     set (t2, "deletefcn", []);
> 198     delete (ax2);
> 199   endif
> 200 endfunction
>
> For me this does not fix the errors, but does illuminate new ones.
>
> Ben

Iit looks to me like the children with invisible handles are not being  
deleted.

Is __go_delete__(h) supposed to delete the children of "h" with  
invisible handles? If not then delete(h) will need to do that before  
calling __go_delete__(h).

To do that it would be convenient if __go_delete__(allchild(h)) would  
work, but it does not for me. Without restorting to a for-loop what is  
the best method to delete the hidden children?

Ben