[Octave-bug-tracker] [bug #55823] [octave forge] (io) xlsread(...) call using OCT interface interferes with GUI editor

[Philip Nienhuis]

Follow-up Comment #7, bug #55823 (project octave):

Even weirder:

If:
(1) I add the following lines into readtest.m without saving the file:
xls = xlsopen (''test.xlsx', 0, 'oct');
xls = xlsclose (xls)

(2) I open xlsclose.m in the editor ('edit xlsclose')

(3) Add a breakpoint at xlsclose L. 121

(4) Back in readtest.m, I select the two newly added lines and press F9 to
execute them

(5) When execution stops at L.2121 in xlsclose.m, I click the "Step into
"button
==> execution continues in __oct_spsh_close__.m

(6) Step all the way through __oct_spsh_close__.m

(7) And when __oct_spsh_close__.m is finished, I step all the way through
xlsclose.m until back in the prompt in the octave terminal,

==> the file readtest.m is still in the editor but I cannot edit it anymore,
it is blocked.
Only thing I can do is click the close button and in the pop-up menu do
"Save", "Discard" or "Cancel".

Trying again, and adding some character to readtest.m after every debug step
in __oct_spsh_close__.m, it turns out it is line 99 in __oct_spsh_close__.m:

rmdir (xls.workbook, "s");

that does it. when I step over it, the editor screen flashes.
When back in readtest.m I press the close button, if clicking "cancel" the
file becomes editable again.

I'm cc-íng the GUI guru; a while ago some fixes were made to the GUI editor
that smell to be related.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?55823>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/