Results 1 to 5 of 5

Thread: delete, deleteLater, do not delete object 'unnamed' in its event handler

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Join Date
    Feb 2009
    Posts
    4
    Qt products
    Qt4 Qt/Embedded
    Platforms
    Unix/X11 Windows

    Default delete, deleteLater, do not delete object 'unnamed' in its event handler

    Hi,

    I'd like to get your opinion on the behaviour of delete vs deleteLater. I've done abit of investigating and would like to know if there's something wrong in my understanding of Qt before raising an issue in TaskTracker.

    I think that Qts throwing a superfluous warning, in a circumstance where it's entirely safe to delete an object.

    If you delete an object from "it's own" event handler, you get a warning at runtime
    'do not delete object 'name' during it's event handler!' which is fair enough, so you use deleteLater, which will post a DeferredDelete event to that object which is serviced after it's other pending events.

    The thing is I think there's a bug where Qt believes it's still in the event handler of the object that originally received the event, even if that object doesn't consume the event and it's passed up to it's parents.

    If we look in QCoreApplication::notifyinternal we see the original event (lets say a KeyPressEvent) to dispatched to the focused widget via

    returnValue = notify(receiver, event); // line561 qcoreapplication.cpp

    Prior to calling notify Qt creates a delete watch on the focused widget, and sets/clears a flag d->inEventHandler before/after it calls notify. This may be incorrect.

    If we go into notify we see that if that event isn't consumed by the focused widget, then it loops upwards through the widgets parents, sending that event to each parent, until the event is eventually consumed.
    e.g. for keypresses see line 3393 qapplication.cpp

    The problem is if one of the parents event handlers deletes the original widget that took the event, you get a warning to not delete the object in it's event handler, because that original d->inEventHandler flag is still set while it loops through all the parents.

    I think that the delete watch should be set for each parent object in the notify loop, instead of being set before notify is called in the first place. This would mean you will only get legitimate warnings for deleting that object in it's own event handler, and then correctly use deleteLater. It should be completely safe to delete the original object from one of it's parents event handlers.

    I've attached a simple test program.
    The button in the window has the focus when the window is shown (i've setFocus anyway just to be sure). When you press 'Q', the keyEvent isn't consumed by the button, and it's sent up to it's parent. The parent then consumes the event and deletes the button, but you get a warning not to delete the button in it's own event handler, but it isn't in it's own event handler, and it is infact completely safe to delete the button from here.

    Any comments or ideas you have would be appreciated.
    Attached Files Attached Files

Similar Threads

  1. Is it bad to delete an object during its event handler?
    By codeslicer in forum Qt Programming
    Replies: 3
    Last Post: 30th December 2008, 16:14

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.