This fixes a bug reported by Willem that removing waypoints
using the right click context menu makes the cylinder
pressure lines partly disappear.
The reason was that clicking a dive handler disables the
pressure interpolation (and other things, controlled by
shouldCalculateMaxdepth). This is turned on again upon
the mouse release event. This event is not triggered when
selecting in item from the context menu (like remove
waypoint or gas selection) so we need to send it manually.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
See also commit c032006d91. Compare functions passed
to sort functions need to compare for less-than and not
less-or-equal.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
In MainWindow::on_actionCloudstorageopen_triggered(),
getNotificationWidget()->hideNotification() was called, thus hiding
any error message produced by the cloud code. Notably, the information
"Cannot sync with cloud server, working with offline copy" was
not shown.
Therefore, remove this call. Note that on cloud save messages were
not hidden.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
CID 45172
And one non initalized member hAxis could be removed as it is
not used. Surprisingly, Coverity did not see this.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This fixes a bug where if the user entered very high ascent (or less commonly
descent) rates such that the time to ascend (or descend) from one level to the
next was less than 10s, that leg would be skipped in the dive plan notes.
Reported-by: Alexander Maier <maieralex@me.com>
Signed-off-by: Rick Walsh <rickmwalsh@gmail.com>
CID 208296. IndexOf can return -1 when not found, which will
not happen in this context, so just to silence Coverity.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
clear_vpmb_state() was declared with incorrect signature, and all
functios in this change are extern, so declare them as such.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
With commit 5962f00679, a well known problem was introduced.
Incorrect width setting for the spanning trip lines. And as there
is even a specific functon for that, just call this.
The reason the mentioned commit introduces this, is that
invalidate() causes layoutChanged signals, and invalidateFilter()
does not.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This is mainly code maintenance. Instead of emitting explicit
dataChanged signals, we can make sure that setStringList()
is called after all model data manipulation is ready. Accoording
to the Qt docs: "The model will notify any attached views
that its underlying data has changed".
In itself, this does not solve the tripped assert mentioned in
commit 5962f00679, but this calling at the end just feels
better.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This "bug" is found using Qt 5.10 compiled in developer mode. Access
the filers, click a little around here, close the filters. Almost every
time the following assert is triggered:
ASSERT failure in QPersistentModelIndex::~QPersistentModelIndex:
"persistent model indexes corrupted", file itemmodels/qabstractitemmodel.cpp, line 643
This is relatively deep down in Qt, and it is triggered by clearing the
filters. Trying to force a crash when using the same scenario in Qt 5.10
compiled for production (so no active asserts) did not result in a crash.
So, upto this time, it is unclear if the Qt assert points out a real problem,
or it is some false alarm (for whatever reason).
Further investigation shows that the assert can be solved by changing the
invalidate() to an invalidateFilter(). Indeed, the last variant is a little
more lightweigt, and does seem to do the same job from a functional point
of view (in this case).
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
DiveLocationFilterProxyModel::lessThan() used less-or-equal instead
of less-than comparison. This can lead to subtle bugs if two elements
compare as equal.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
FilterModelBase is a direct subclass of QAbstractItemModel. Therefore,
dynamic_cast<>ing the former to the latter is unnecessary. Probably
an artifact of previous code.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Realistically this is a false positive as we should never use a second
BTDiscovery instance - but there's nothing wrong with being extra certain.
Coverity CID 208319
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The previous attempt to fix this in commit 652e382e68 ("Cleanup: avoid a
few memory leaks") was clearly bogus. Oops.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
