Frame 'close' button event?

[steved]

The recently updated frame handler is much more memory efficient, but a side effect is that we've lost the ability to notify a frame close (destroy) event. Previously I assigned a tag value to the 'frame close' button, so got an identifiable touch event on frame close, which I could use to reset some of my own logic.

I can see possible ways to restore this functionality - probably by triggering a button event on close if the frame tag value is non-zero. Any better ways?

[inmarket]

I will re-add this event for you asap.

I am thinking of adding events for all gwin significant opens such open, close, resize. Now might be the time to do it.

[inmarket]

This has now been fixed and a GEVENT_GWIN_CLOSE event is now sent.

Because I have changed the structure slightly for GWIN events you may have some small changes to make in your code.

Basically pe->button, pe->slider, pe->frame, pe->list etc have all been renamed to pe->gwin (being the handle of the window creating the event). All GWIN event structures now have the same "type", "gwin" and "tag" elements.

[steved]

Thanks for this - makes sense to have a uniform behaviour.

Actually the event sending action needed adding in two places, not one.

The attached works on a quick check - note that if the event is sent before the _gwinDestroy() call, it appeared to lock up the system. However I'm not sure whether the line I've added is accessing freed up memory - certainly it would be logical to send the event prior to the _gwinDestroy() call.

Also note a possible typo around line 312 where I've made a change (not tested)

frame.zip

[inmarket]

Good catch. It is now fixed in the repository.

There are two cases for the close - one with GWIN_BUTTON_LAZY_RELEASE and one without. In one case it was using the wrong destroy routine which would have caused the lockup, in the other it wasn't sending the close event.

The close event MUST be sent before the destroy because the send code accesses the structure to get the tag to put into the event.

You are right, line 312 was a typo and has also been fixed.

Thanks.