As before, I deeply appreciated the Ext.Net (also known as Coolite) extensions over the core ExtJs (both server-side and client-side), and how well they integrated with ExtJs, making them look-like part of core ExtJs itself. And this time, it was the turn of the Ext.Net’s Notification class to get me to make such a statement.

This class provides a great non-obtrusive way to present Notifications to the user (unlike the ExtJs’ MessageBox, which forces user interaction). What’s more, it provides quite a bit of flexibility through config options like autoHide/hideDelay/pinned etc. which should cover almost any scenario. Not to be in my case, however.

Now in my situation, what I wanted was the ability for the user to close the Notification, while still auto-closing the Notification after a time-out if the user himself/herself did not close it already. This meant that I wanted the “Close” button on the Notification, while auto-hiding it after a timeout.

But, the Notification class’ show method (Ext.net.Notification.show) itself supported only one of these two scenarios out-of-the-box. That meant that you can either have a “Close” button on the Notification, or auto-hide it. There was a work-around of specifying the pinEvent config option, which would automatically pin the Notification on an event (like click, mouseover, or mouseenter etc). However, there were some disadvantages using this config option. One, you need to educate user about this event that it would pin the window. Second, after the Notification gets pinned, it loses its autoHide behavior, and needs to be closed explicitly. Third, if you specify mouseEnter etc as pinEvent, it might take the browser a bit of time to recognize that event.

And I wanted none of these. I wanted that window should autoHide after a timeout unless the user closed it explicitly, or the window was pinned, or the mouse was over the window.
Did you notice the window word in the above line. Yes, Ext.net.Notification.show actually creates a normal Ext.Window with some added listeners. It also returns the window created for you to manipulate it afterwards.

Before discussing further, let us see the code I came up with to achieve my desired objective:

{syntaxhighlighter brush: jscript;fontsize: 100; first-line: 1; }var w = Ext.net.Notification.show({
alignToCfg: {
offset: [-210, -125],
position: ‘tl-br’,
el: pnl.el
},
autoHide: false,
hideDelay: 4000,
title: ‘Title’,
html: ‘Body.’,

autoHideNotification: function() {
this.hideTask = new Ext.util.DelayedTask(this.hide, this);
this.hideTask.delay(this.hideDelay);

var mOver = function(e, t) {
if (!this.pinned) {
this.hideTask.cancel();
this.delayed = true;
}
},
mOut = function(e, t) {
if (!this.pinned) {
this.hideTask.delay(this.hideDelay);
this.delayed = false;
}
};
this.body.on(“mouseover”, mOver, this);
this.body.on(“mouseout”, mOut, this);
this.header.on(“mouseover”, mOver, this);
this.header.on(“mouseout”, mOut, this);

}
});
w.autoHideNotification();{/syntaxhighlighter}

There are 2 interesting things to note above:

1.  I specified both (contradictory) config options to the show method: autoHide: false, and hideDelay: 4000
2. An additional custom method autoHideNotification has been passed in the config to the show method.

The show method itself gives precedence to the autoHide config option, and thus the Notification appears with the “Close” button.

The autoHideNotification method takes care of the rest. It attaches various listeners to the Notification window, and takes care of auto-hiding the window after the timeout specified in the original config (because of which I specified those contradictory config options. The show method ignores the hideDelay option here, but the custom method takes good care of it).

The custom method (autoHideNotification) honors all config options of the show method. Specifically, if the Notification is pinned (either by the pinned config option, or through the pinEvent config option), there is no auto-hiding. Plus, auto-hiding is disabled for the time the mouse is over the Notification.

The important thing to also notice is that the return value of Ext.net.Notification.show has been stored and the custom method has been called on the return object (which as said above is the reference to the Notification window) immediately. Without this, the approach would not work. Thus you need to call autoHideNotification explicitly on the return value of the Ext.net.Notification.show method.