Closing the main qnet window after modifying control net and hitting "Cancel" closes the main window
Minimal - Affected applications include qnet, as well as QnetFileTool, and ViewportMainWindow.
This occurs (on Fedora21) when running qnet and modifying a control network (by either changing points in an existing control network or creating a new control network).
When closing the main qnet window (clicking the window's close / X button), a prompt will appear:
QnetTool The control network files have been modified. Do you want to save your changes? [Cancel] [No] [Yes]
Clicking Cancel will close the main qnet application window, but qnet will still be running.
This bug does not occur when using **File->Exit* or the CTRL-Q shortcut to quit and then clicking Cancel on the dialog.*
- Status changed from In Progress to Resolved
- Impact updated (diff)
This was caused because we connect the ViewportMainWindow::closeWindow() signal directly to the QnetFileTool::exit() slot.
The exit() slot prompts the popup dialogue, and if 'cancel' is selected it simply returns from the exit function. The CloseWindow() is emitted from the window's closeEvent() method, which emits that signal but then proceeds to close the application anyway with no regard to what happened in the listening exit() slot.
There was insufficient communication between these two programs.
The solution was to pass a pointer to the QCloseEvent object that ViewportMainWindow receives when closed, and pass that into the QnetFileTool's exit() slot so that we could set that QCloseEvent to be ignored if the "cancel" option was clicked.
These parameters were added as optional parameters to address backwards compatibility and not interfere with applications that were listening for a ViewportMainWindow::closeWindow() signal that wasn't populated with a QCloseEvent object.
Changes can be found in /work/projects/isis/latest/m04146 and have been built on prog24 for testing.