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

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

[Octave-bug-tracker] [bug #46795] dbstop lacks much Matlab functionality


From: Lachlan Andrew
Subject: [Octave-bug-tracker] [bug #46795] dbstop lacks much Matlab functionality
Date: Thu, 07 Jan 2016 11:08:21 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0

Follow-up Comment #11, bug #46795 (project octave):

The reason that the restore breakpoints dialog is activated is in the code
libgui/src/m-editor/file-editor-tab.cc


void
file_editor_tab::handle_file_modified_answer (int decision)
{
  if (decision == QMessageBox::Save)
    {
      // Save file, but do not remove from editor.
      save_file (_file_name, false);
    }


This shows that the save_file code is called believing that the tab will stay
around.

This is called from the function with the following comment:


file_editor_tab::check_file_modified ()
{
  int decision = QMessageBox::Yes;
  if (_edit_area->isModified ())
    {
      // File is modified but not saved, ask user what to do.  The file
      // editor tab can't be made parent because it may be deleted depending
      // upon the response.  Instead, change the _edit_area to read only.
      QMessageBox::StandardButtons buttons = QMessageBox::Save |
                                             QMessageBox::Discard |
                                             QMessageBox::Cancel;


which suggests that the dialog should call save_file with the "close after
saving" option.  However, I suspect that will cause problems with the signal
emitted by


file_editor_tab::closeEvent (QCloseEvent *e)
{
  _cancelled = false;  // prevent unwanted interaction of previous
                       // exits of octave which were canceled by the user

  if (check_file_modified () == QMessageBox::Cancel)
    { // ignore close event if file is not saved and user cancels
      // closing this window
      e->ignore ();
    }
  else
    {
      e->accept ();
      emit tab_remove_request ();
    }
}



Perhaps the solution is to call the save_file with the close-after-save option
and check for three possible values of check_file_modified(), instead of just
checking whether or not it was "cancel".

Does that sound OK, Torsten?  If so, I'll create a separate patch for that.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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