stickyWinHTML layout update: big close/ok buttons
I added large close and confirm buttons to the default stickyWinHTML layout. You can make them read whatever you want and you can assign callback functions to them getting clicked. They are optional, and not visible by default. Note the section in the link above about how the onClose event is NOT the same as the onClose event for StickyWin.
That little "x" for closing the StickyWin is pretty small, and on pages like in our CMS, I think an easier to click close button would make it easier to deal with these things, especially if you end up opening them often. If you don't specify a closeTxt or confirmTxt value, the buttons are not there. The callbacks are not required. Example:
JavaScript:
new StickyWin({
content: stickyWinHTML('the caption', 'this is the body', {
width: '400px',
closeTxt: 'close',
confirmTxt: 'okey-dokey',
onClose: function(){alert('closed!')},
onConfirm: function(){alert('confirmed')}
})});
content: stickyWinHTML('the caption', 'this is the body', {
width: '400px',
closeTxt: 'close',
confirmTxt: 'okey-dokey',
onClose: function(){alert('closed!')},
onConfirm: function(){alert('confirmed')}
})});
new StickyWin({
content: stickyWinHTML('the caption', 'this is the body', {
width: '400px',
closeTxt: 'close',
confirmTxt: 'okey-dokey',
onClose: function(){alert('closed!')},
onConfirm: function(){alert('confirmed')}
})});
content: stickyWinHTML('the caption', 'this is the body', {
width: '400px',
closeTxt: 'close',
confirmTxt: 'okey-dokey',
onClose: function(){alert('closed!')},
onConfirm: function(){alert('confirmed')}
})});
This is cool, but just one comment. The close icon in the corner upper right corner should also execute the onClose function if defined. In other words, it should behave the same as the close button. What do you think?
I thought about that, but what I wanted to do was distinguish between the StickyWin closing - which is an option of StickyWin - and the big close button, which can read whatever you want it to read. You basically have two buttons that can mean anything. You could have one that says "new window" and another one that reads "ok" and the little "x" just closes the box.
All three buttons execute the onClose event in StickyWin, so if you want something to occur when the user closes the window, you can specify that option in the StickyWin instance.
That said, I'm open to change it. If people find they want it to behave differently and are having to hack around my implementation, that's no good.
Yeah, you make sense. I will have to play it with first and revisit some of my use cases.
Anyway, as usual, I appreciate your continued work on these libs, I love 'em!
I love the stickywin widgets, but I'm a little unclear as to how to call my own function when the X is used to close the stickywin. Does the onClose in the options NOT get called when you click the X? The onStart doesn't seem to be working for me either, so I must be just using them wrong.
Thanks!
The important thing to remember is that there's a difference between the big close button (which is created with the stickyWinHTML function) and the event that occurs when the window is closed.
onDisplay and onClose are events tied to StickyWin, but stickyWinHTML - which just creates the layout and can have these buttons - can have functions tied to those buttons. When either is clicked, they will close the StickyWin and fire its onClose event. This might help a little bit:
content: stickyWinHTML('the caption', 'this is the body', {
width: '400px',
closeTxt: 'close',
confirmTxt: 'okey-dokey',
onClose: function(){alert('clicked close button')},
onConfirm: function(){alert('clicked confirm button')}
}),
onDisplay: function(){alert('display');},
onClose: function(){alert('close sticky')}
});
content: stickyWinHTML('the caption', 'this is the body', {
width: '400px',
closeTxt: 'close',
confirmTxt: 'okey-dokey',
onClose: function(){alert('clicked close button')},
onConfirm: function(){alert('clicked confirm button')}
}),
onDisplay: function(){alert('display');},
onClose: function(){alert('close sticky')}
});
Corrected code example above; had onDisplay in there twice
That's what I thought. I'm not using the stickyWinHTML or the buttons, just a stickyWin and using the closeSticky classed anchor to close the stickyWin. Even when I strip it down to a simple test, like below, it never pops up my alert... neither display nor close. Some version incompatibality maybe?
var x = new StickyWin({
content: $('stickyWinContent').innerHTML,
onDisplay: function(){alert('display');},
onClose: function(){alert('close sticky')}
});
Are you using the copy of Mootools in my SVN, or one from Mootools.net? If from Mootools.net, are you using the dev version or the current "public" version?
Try downloading from my SVN the clientside.moo.v1.packed.js file (in trunk/cat/) and seeing if it works on your page with that.
I was using the dev version from Mootools.net. Actually the official 1.0 released version I was having some problems with the ajax callback not getting called. Switching to dev cured that. I just tried the clientside.moo.v1.packed.js file and both ajax and the stickyWin onClose function are working, although the onClose is getting called twice. Still, that's much better. Thanks
Any chance you can give me some hints on why the onClose in StickyWin wouldn't be working with Mootools after 1.0, specifically the latest SVN? My stickyWin hangs IE 7.. basically if I have a bunch of links and events going on in the popup, I can get IE7 to hang after a bit. This doesn't happen with the latest mootools, but I really need the onClose functionality. Any pointers or tips would be greatly appreciated.
Thanks
Hmmm. I'd need to see it in action. Which release of the SVN are you using? Have you tried your code with the version in our SVN release? This might tell us if it's a change in Mootools that is the problem, a problem with my code, or a problem with yours. If you can give me these answers and point me at an example, I might be able to help.
Ok, I think I figured out my problem. Regarding the onClose not working, it appears that I had a version out of sync, possibly the stickyWin.js, but I'm not sure. I grabbed fresh copies of everything and that seems to have cleared it up. I'm now using mootools.net rev 430 with your svn trunk for the clientside. The hanging of IE7 seems to have been because in the onClose, I was trying to clear the stickyWin myself (to kill a sound that continues to play after the stickyWin is closed) and apparently it really didn't like that... my bad #2.
Here's a problem I'm still having though. It appears the stickyWinModal leaks memory in IE7. If I just create a simple modal with no crazy functionality and keep opening and closing it, I get the stair step action like you mention in your article on "Screencast on Diagnosing Memory Leaks in IE."
BTW, you're doing a hell of a job here. Your widgets and your articles have been invaluable in my efforts and are greatly appreciated. Keep up the good work, please.
Thanks
I can't reproduce this Jim. Here's the memory chart of me creating a StickyWinModal and refreshing the page and doing it again in IE7 (using the example in the wikitorial):
Can you point me at the page where this is happening to you?
Yeah when I refresh the page in between popups, it's fine. It's when I don't refresh the page and just keep opening and closing the same stickyWinModal... or when I have links that will pop up a number of stickyWinModals on one page and go from one to the next without refreshing the page. That's when I see the stair step. The more content in the window, the more pronounced the step... is there something I'm not doing correctly to release the modal when I close it?
I don't have a page I can point you to at the moment... I'll try to get an example later tonight.
IE, for some odd reason, eats memory when you create a big block element (in this case, the modal layer). If I were a betting man, I'd bet that it creates a bitmap or something that it renders the whole page with. The bigger the element, the more bits, the more bytes, etc.
Modalizer re-uses the same modal layer over and over again, so if you create 10 of them, they all point to a single DOM element. I do this precisely because of how IE eats memory for each one. If you have altered Modalizer so that it will create numerous layers, you'll see it eat memory for each one.
Yay MSFT.