some of the pop-ups do not force a postback refresh , its only those that can cause a datachange to the underlying page. I believe there is an issue logged to look at this further but the problem is that a popup may allow a user to make a number of updates before closing so to be safe we force a refresh. \if you feel that a particular sequence does not require this then please log it at support.dotnetnuke.com

---

Buy the new Professional DNN7: Open Source .NET CMS Platform book Amazon US

The biggest issue that I see with popups - after working with them for some time - is that there is no real concept of STATE management inside the POPUP window.

Seems to me that modules that support popups need a better api that allow them to register STATE changes using something as simple as a DIRTY flag = within the current popup,

The use of popups has been locked down to a point where ONLY modules that "support" popups use the popup system - SO - such modules should be able to be changed to properly support a STATE.

And really it does not need to be complex . . . we already KNOW when we are inside a popup that is going to cause a page refresh
 - the URL of the popup has /*showReturn*/ true  in it for starters.

SO those modules should be able to know how to register their state in a useful way that the popup api could use to determine if the CANCEL button OR  the CLOSE button - show return WITHOUT causing a post back.

Basically - what im suggesting is that when the popup is first opened = something like a javascript coookie is used to hold a STATE value - each popup cycle starts off with a value of DEFAULT - while this value is set the action of the CLOSE button will be to force a REFRESH - as at this point the popup does not know  if the module is compliant with the state system.

Modules that ARE compliant need to register this with the popup - by including a register call that changes to javascript cookie state to = CLEAN.

Once the state is set to CLEAN the popup system can then close the popup without causing a page refresh if the user hits the close button.

Modules that DO support the STATE and have set the CLEAN value - are then responsible for handling the STATE value correctly.
They would do this by changing the STATE value to DIRTY when that module performs any action  demands a page refresh.

Westa