Avoid chrashes when reloading todos as discussed with Volker. This could happen when multiple todos got deleted and thus their todo pointers got invalid. Because todo items are only deleted one by one we have to prevent the access to other todo items which are about to be deleted. This access is caused by views which respond to the rowsRemoved() signal emitted while deleting a todo item. Then they can access other todo items which are about to be deleted too, and whose todo pointers are invalid. Now it is checked if todo items are about to be deleted before accessing the pointers in data() and flags().
Avoid chrashes when reloading todos as discussed with Volker.
This could happen when multiple todos got deleted and thus their todo pointers got invalid.
Because todo items are only deleted one by one we have to prevent the access to other todo items which are about to be deleted.
This access is caused by views which respond to the rowsRemoved() signal emitted while deleting a todo item. Then they can access other
todo items which are about to be deleted too, and whose todo pointers are invalid.
Now it is checked if todo items are about to be deleted before accessing the pointers in data() and flags().

Also, a minor optimization was included which should speed up reloading of todos a tiny bit when a lot of
todos got deleted (at least in release builds).

Volker, could you please test again with your setup?

CCMAIL: vkrause@kde.org

svn path=/trunk/KDE/kdepim/; revision=813626

lefou/kdepim-noakonadi,lefou/kdepim-noakonadi,lefou/kdepim-noakonadi,lefou/kdepim-noakonadi,lefou/kdepim-noakonadi,lefou/kdepim-noakonadi