window.opener attribute not set after postback

[MrFez]

I have an webform from which I open a child window to display a calendar.
When a date is selected in the calendar window it attempts to set the value
of a textbox in the main (parent) window by using the window.opener property
to reference the textbox.

Everything works fine initially. However if the the main window does a
postback and the calendar is re-opened, its window.opener property will
always be null.

So: BEFORE main window executes a postback the calendar can be opened,
close, and re-opened many times and window.opener is set properly.

AFTER main window does a postback (another button was clicked) the calendar
window can be opened but it cannot return a value because window.opener is
always null.

Note, this seems to be primarily a problem with Windows XP SP2 clients.
Windows Server 2003 SP1 clients do not seem to have this problem.

Any ideas?

[MrFez]

Further investigation has revealed that this problem occurs when the "Check
for newer versions of stored pages" setting of IE is not set to
"Automatically".

Specifically, the clients that were not working were set to "Every visit to
the page". When I changed them back to "Automatically" the problem went away.

However, because of other issues I want then set to "Every visit to the page".
"MrFez" wrote:

I have an webform from which I open a child window to display a calendar.
When a date is selected in the calendar window it attempts to set the value
of a textbox in the main (parent) window by using the window.opener property
to reference the textbox.

Everything works fine initially. However if the the main window does a
postback and the calendar is re-opened, its window.opener property will
always be null.

So: BEFORE main window executes a postback the calendar can be opened,
close, and re-opened many times and window.opener is set properly.

AFTER main window does a postback (another button was clicked) the calendar
window can be opened but it cannot return a value because window.opener is
always null.

Note, this seems to be primarily a problem with Windows XP SP2 clients.
Windows Server 2003 SP1 clients do not seem to have this problem.

Any ideas?