On Thu, Mar 12, 2015 at 12:25 AM, Lubomir I. Ivanov <[email protected]> wrote:
> hey Miika, > > this prevents deletion of divepoints on a newly added dive completely > (Log -> Add dive): > > http://trac.subsurface-divelog.org/changeset/4f9705f3f54fc14d6b38123160f07015c41f3519/subsurface > It is also related to 6f795a0059f5b1540d62bab30bc62422717420bb > new bug report: > http://trac.subsurface-divelog.org/ticket/846 > > i can't really reproduce what the comment describes: > * If we end up having divepoints that are not within the dive > * profile, we need to just skip the removal to prevent > * crashing due to index out of range. > > i always get this for any dive: > rowCount() == divepoints.count() > can you provide steps? > The bug was not really deterministic. When moving a divepoint around and releasing it, it was occationally possible to drop the point so it was not on the profile. Bug 784 might give a better idea of how to reproduce, even though it was not that obvious. > but also, shouldn't the check be like so?: > if (rowCount() > divepoints.count()) > Sounds about right, if the normal case is they are the same. I do not recall the exact details and cannot dig into this at the moment. > i wonder how is it even possible for divepoints to not be a part of > the dive profile. > I couldn't figure out why the bug happened, but it is worth a try to debug it further/again. > if there another underlying bug here perhaps we should remove the > check and fix that instead... > Absolutely, if someone is just able to figure out how this can happen in the first place. miika
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
