Results 1 to 5 of 5

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

  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

  2. #2
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,364
    Thanks
    3
    Thanked 5,013 Times in 4,791 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

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

    From a logical point of view it is still in its own event handler. The fact that the event propagates to parent doesn't change the fact that it was directed to the original object in the first place and the caller has no way of knowing what (if anything) consumed the event. You are only considering one possibility of using the event mechanism, whereas for example it would be stupid if you did this:

    Qt Code:
    1. void X:something(){
    2. QMouseEvent me(...);
    3. QApplication::sendEvent(somewidget, &me);
    4. someWidget->doSomethingElse(); // kaboom!
    5. }
    To copy to clipboard, switch view to plain text mode 

    sendEvent() would deliver the event to the object, it would propagate, the object would be deleted without you knowing and then you would try to access the object again which would make your application commit suicide.

    There is nothing wrong in using deleteLater() instead of delete so it's better to be more safe than you really need than to get your app killed. At least that's my opinion.

  3. #3
    Join Date
    Feb 2009
    Location
    Noida, India
    Posts
    517
    Thanks
    21
    Thanked 66 Times in 62 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11 Windows

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

    i ran ur code, and it didnt emit any warning.. i m using QT 4.4.3..which version are u using

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

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

    Quote Originally Posted by talk2amulya View Post
    i ran ur code, and it didnt emit any warning.. i m using QT 4.4.3..which version are u using
    4.4.0.. did you press Q? that triggers a keypress event which will delete the button from the main window widget. (note the button doesn't do anything if you press it - i just used that cos it takes focus and shows how the events propogate).

  5. #5
    Join Date
    Feb 2009
    Location
    Noida, India
    Posts
    517
    Thanks
    21
    Thanked 66 Times in 62 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11 Windows

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

    yes, i read your code and i pressed 'q' and the button got deleted without any warning or crash or anything..maybe they went ahead and removed the warning as u wished for, in 4.4.3 ..nice catch i guess!

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, 17: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.