Add a helper function to unify the calculation of the
weight display string, instead of having the same calculation
in two places in the code.
Signed-off-by: Benjamin Fogel <nystire@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
DiveComputerList::getExact() created a temporary QList with the
DiveComputerNodes matching a specific model. A pointer to a node in the
list was returned, which becomes invalid when the list goes out of scope
and gets destroyed. Causing a crash when the model strings are compared
later.
Instead of using contains() and creating a temporary list, we can just
use an iterator, which should be both faster and safer.
The crash is easy to trigger with DM4 imports, but can probably be
triggered in other cases too.
Similar problem with DiveComputerList::get().
Signed-off-by: Michael Andreen <harv@ruin.nu>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This sneaked into commit 9364436264.
It shouldn't be there.
Signed-off-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The compiler on MacOSX seems stricter than others:
qthelper.cpp: In destructor ‘DiveComputerList::~DiveComputerList()’:
qthelper.cpp:10: error: expected class-name before ‘(’ token
Fixed with help from http://stackoverflow.com/a/14777627/13365
Signed-off-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This data structure was quite fragile and made 'undo' when editing
rather hard to implement. So instead I decided to turn this into a
QMultiMap which seemed like the ideal data structure for it.
This map holds all the dive computer related data indexed by the model. As
QMultiMap it allows multiple entries per key (model string) and
disambiguates between them with the deviceId.
This commit turned out much larger than I wanted. But I didn't manage to
find a clean way to break it up and make the pieces make sense.
So this brings back the Ok / Cancel button for the dive computer edit
dialog. And it makes those two buttons actually do the right thing (which
is what started this whole process). For this to work we simply copy the
map to a working copy and do all edits on that one - and then copy that
over the 'real' map when we accept the changes.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
