Qt Commercial Support Weekly #12 - To delete or not to delete

As a great literary developer may have once said, "To delete or not to delete, that is the question." As we know, with C++ we are expected to clean up after ourselves whenever we do something new so that the memory is available and does not cause a leak.  Of course, Qt makes this easier for us to manage as we have the parent-child relationship with QObject based objects.  Therefore, whenever the parent object is deleted it will delete its children for us, thus saving us from having to remember or worry about ensuring they are deleted.  

Qt doesn't prevent us from deleting objects directly. However, if we have a need to do it, and if you delete an object that has a child, then it will ensure that it is removed from its parent automatically so you don't need to worry about double deletion.  However, there are some circumstances that you need to be careful of when deleting a Qt object directly, particularly when in an event handler or in a slot that is connected to a signal.

In a case where you have a setup where you call a function on a widget, you wouldn't expect to be able to do a "delete this;" as this would cause a problem when the function returns or if you do something else after that.  The same principle applies when you decide to delete a widget inside an event handler or in a slot that is directly connected to a signal.  What you need to think of, in this case, is whether the widget you are deleting has triggered the event or the signal that is fired, even if it is a case of the event having propagated through the widget (such as a mouse press event).  If this is the case, then you cannot call delete directly on this widget because Qt will expect it to still exist when the control returns back from the event handler or the slot.

Luckily for us though there is a way to actually delete these widgets in this case, as in QObject there is a function called deleteLater().  What this function does is posts an event that will effectively cause the widget to be deleted as soon as the control returns to the event loop.  So, when the event handler has been finished with or the slot returns, then it will safely delete the widget in question for us.  You can still set the pointer to be 0 right after calling deleteLater() so it is just a case of swapping "delete widget" for "widget->deleteLater()".

So if you find yourself experiencing a crash due to a deleted widget, then try using deleteLater() instead and see if it makes a difference.

In other news, for those who use the customer portal, a tip came in from a customer.  If you need to submit more than one case with the same details, then first fill it in without a subject set, then click on submit.  Next, add the subject and click submit.  Then, if you use the back button in the browser, it will present you with the form with all the details filled out for you.  Hopefully, that will be of some use to you!

Until next week, happy coding :)