feature request: optionally deleting the whole chain of event handlers, when window is deleted

[chris]

>  This is too unsafe to consider. There can be some unrelated code somewhere
> which pushes its own event handler on your window and then deletes it
> itself which is a perfectly valid thing to do, but with this approach it
> would be deleted twice.

I'm quite sure that if one EventHandler is deleted, it will be deleted
from the linked list containing all chainded handlers. So this
wouldn't happen.
But:
> Besides, it doesn't make sense API-wise: what if
> you call PushEventHandler(handler1, true) and then PushEventHandler(handler2,
> false)?

This argument counts, definitly. This would be a poor implementation.

> c> That's because I dont want to call 'delete this' anywhere.
>
>  Is there any reason for this?

Yes. Try googling for 'delete this'. It's not known as a good design
choice.

>
> c> But using the flag mentioned above would be a quite cleaner and more
> c> flexible solution. We wouldn't be restricted to the windows wich are
> c> sending an event, when they are closed and we wouldn't have to watch
> c> for wxEVT_CLOSE_WINDOW all the time.
>

>  I don't see any problem with catching wxEVT_CLOSE_WINDOW
> nor do I really
> see why would the other approach be more flexible.

I thought of rereading the manual before posting my answer:
Now that I know that EVT_CLOSE workes for *every* wxWindow, not just
for top level ones, I dont see any problem with flexability.

But I'm still not sure what happens in the following case:
I have a dialog,  containing some controlls for which i provide some
of my extra event handlers.
I'm not sure how the event handlers are ordered.
Say wxEVT_CLOSE_WINDOW will first be caught in my manager object
first, because the user has pressed the 'OK' button. Here I delete all
the extra event handlers and say event.Skip(), so the default dialog
behaviour can happen.
Now at some place else this event will be caught again and the
application for some reason decides not to close this dialog.
In this case all my extra event handling is gone.

But using my own wxDialog derived class, which calls Close(true), when
user presses the 'OK' or 'CANCEL' buttons will hopefully eliminate
this problem.
So i withdraw my request.

Thanks for the discussion.
Chris