//I agree, can we push this for consideration at Sencha?
vote++;
Printable View
//I agree, can we push this for consideration at Sencha?
vote++;
If I understand it right, then close() is just an alias for hide() or destroy(), depending on what closeAction is set to. In previous versions I always destroyed the Notifications, but in the last version I changed the behavior. The default closeAction of a window is 'destroy', but it can also be set to 'hide' if reusing the window is desirable. The latest changes I made make it possible to reuse a notification object the same way.
For example if you check out the latest demo (http://www.eirik.net/Ext/ux/window/Notification.html) there is a button that says "BR - reuse". This shows the reuse of the component and the dom. A nice side effect in the example is that this automatically restricts the number of notifications to only one.
And the script actually does not call hide() more than once. From inside the overridden destroy() function. The reason for this is to make sure the notification fades out with an animation not only when the script closes it after the delay (autoClose), but also when the close button in the top right hand corner is clicked. There might be a way of achieving this without touching the destroy() function, but I felt it made sense to always hide the notification with the animation before it is destroyed.
After the hide animation is finished a new call is made to destroy() and the second time around a call is made to me.callParent(arguments) inside destroy(). So I am under the impression that this means all other destruction that windows normally perform will take place. The dom certainly is destroyed and I figured that was mostly what the destroy() functions did in Ext (take down the related dom). If there is a memory leak caused by the overriding of the destroy() function, then maybe that is because something else, like a pointer or circualar reference, should also be destroyed before exiting the overridden destroy() function. But since hide() calls removeFromManager(), then I can't imagine where those pointers are.
When it comes to memory management I'm on thin ice. Both JS and Ext wise. So maybe somebody could help out with some more insight? Or simply tell me a procedure I could use to test/visualize the leak, providing me a way to debug it.
View the source from the demo page:
http://www.eirik.net/Ext/ux/window/Notification.html
Great extension. I apologize if this was noted already, but how do I make a notification stick until it's manually closed or I close it programatically?
Thanks.
Is there a way to either reuse or prevent multiple notifications appearing (that are the same)?
Yes. In the demo there is a button called "BR - reuse" demonstrating exactly how to do this.
In short you store the pointer to the notification when you create it. This can be done in advance as long as you don't call the show() immediately. And then you only call update/show every time you want to notify something. If the notification is still visible when the next updtae/show is called then all that happens is an update of the notification's content.
in 4.2 fails to destroy the component.
so it works again:
Code:hide: function () {
var me = this;
// Avoids restarting the last animation on an element already underway with its hide animation
if (!me.isHiding && me.el) {
me.isHiding = true;
me.cancelAutoClose();
me.stopAnimation();
me.el.animate({
to: {
opacity: 0
},
easing: 'easeIn',
duration: me.hideDuration,
dynamic: false,
listeners: {
afteranimate: function () {
me.removeFromManager();
me.readyToHide = true;
if(!me.destroying){
me.hide(me.animateTarget, me.doClose, me);}
}
}
});
}
...
Animation fails in ExtJS 4.2.1 beta 1