mirror of
https://github.com/subsurface/subsurface.git
synced 2025-02-19 22:16:15 +00:00
Undo: make adding of planned dive undo-able
Planned dives were still added by directly calling core code. This could confuse the undo-machinery, leading to crashes. Instead, use the proper undo-command. The problem is that as opposed to the other AddDive-commands, planned dives may belong to a trip. Thus, the interface to the AddDive command was changed to respect the divetrip field. Make sure that the other callers reset that field (actually, it should never be set). Add a comment describing the perhaps surprising interface (the passed-in dive, usually displayed dive, is reset). Moreover, a dive cloned in the planner is not assigned a new number. Thus, add an argument to the AddDive-command, which expresses whether a new number should be generated for the to-be-added dive. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This commit is contained in:
parent
e0fcf99d0a
commit
b19adecb9f
7 changed files with 52 additions and 50 deletions
|
@ -890,19 +890,11 @@ void MainWindow::planCanceled()
|
|||
|
||||
void MainWindow::planCreated()
|
||||
{
|
||||
// get the new dive selected and assign a number if reasonable
|
||||
graphics()->setProfileState();
|
||||
if (displayed_dive.id == 0) {
|
||||
// we might have added a new dive (so displayed_dive was cleared out by clone_dive()
|
||||
dive_list()->unselectDives();
|
||||
select_dive(get_dive(dive_table.nr - 1));
|
||||
dive_list()->selectDive(get_divenr(current_dive)); // TODO: don't convert dive->idx and back
|
||||
set_dive_nr_for_current_dive();
|
||||
}
|
||||
// make sure our UI is in a consistent state
|
||||
information()->updateDiveInfo();
|
||||
showProfile();
|
||||
refreshDisplay();
|
||||
setApplicationState("Default");
|
||||
dive_list()->setEnabled(true);
|
||||
dive_list()->setFocus();
|
||||
}
|
||||
|
||||
void MainWindow::setPlanNotes()
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue