I doubt it's fair to blame Microsoft for this. If I understand your problem correctly, this problem is largely caused by the loosely coupled, disconnected and stateless nature of the web in general, not because of the way Microsoft have implemented .NET....

Imar


---------------------------------------
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Everyone is unique, except for me.
Author of Beginning ASP.NET 3.5 : in C# and VB, ASP.NET 2.0 Instant Results and Dreamweaver MX 2004
Want to be my colleague? Then check out this post.

Nope, the meta tag refresh also loses the selection form field values when the refresh occurs. I'll have to find some other work around.

Thanks!

Imar,

Sorry, you're right (although MS is to blame for 95% of the worlds woes, of course, even those not involving computers). :D

For inquiring minds, the closest I was able to get was to force a refresh after the records are saved. And even that work-around nearly caused a brain aneurysm, as it was necessary to use a Response.Write in the code-behind to pass the reload script to the Submission Form returned once the updates are completed.

If anybody has a suggestion that does not require changing my page from METHOD=POST to METHOD=GET, I'm still interested in a more elegant solution.

Thanks!

So a simple question to you:

Do you have an <asp:button> on that page that will, effectively, refresh it???

That is, how are you having your users refresh it now? If they hit the browser REFRESH (F5), they will get that same "resubmitting post data" message (yes, in *any* browser...message differs, but it's a security measure that browsers are *supposed* to implement, just so that evil scripters can't do bad things). So when you posted your original message, did you have a scheme in mind for allowing people to refresh without needing to hit F5? Hopefully, some <asp:button>???

If so, then just have the code "push" that same button, instead of doing the reload() call.

That is:
    window.opener.document.forms[0].nameOfThatButton.click();
or
    window.opener.document.getElementById("id of that button").click();

If you don't have such a button, could you create one?

Note that you could even hide the button from the user, if you wanted, using an appropriate style. Just make sure it posts the correct info back to the server to refresh the data on the page.

And you probably already discovered this by now, but...
    "...I was not aware that IE kept track of which windows were opened by which other browser windows..."

Not just IE. All browsers, that I know of. Possibly excepting some of the old text-only browsers.

The dialogue box about resending the info means that a post was involved when the page was created. Have you tried:--

Joe (Microsoft MVP - XML)

Old Pedant:

There was no button originally, although I tried going that route as well as many other solutions I stumbled across on the web. There appeared to be no difference between coding a button, a function, or clicking F5 - it still displayed that *&^%$ dialog box. So calling the button, hidden or not, still forces the users to click yet another button, and our users dislike having to click even one button. Automatically refreshing on update works as effectively, although I consider it an incomplete solution. At least the report disappears and the users HAVE to do something to get it back, unlike the way it was, where they weren't even bothering to refresh despite urging them to frequently do so. If I could get it to submit the refresh ONUNLOAD, I'd have done that instead, but it kept telling me that the window object didn't exist so I gave up going that route.

While some of our users are undoubtedly evil, most of them are just ignorant, and ALL of them are identifiable, because this is an INTRANET site with no external access. Furthermore, we are a gov't agency with the authority to legally punish any employees out to hack our system. It's therefore very unlikely that anybody would submit anything to screw with the system and this "security feature" is clearly unnecessary in our environment (and I would think others maintaining Intranet sites would have a similar issue). There really ought to be a way to submit a refresh and override that unnecessary dialog in such circumstances, but I expect I am singing to the choir when it comes to the many limitations associated with developing web applications. Hello, W3C?

joefawcett:

I tried that, too. Problem with setting href is that the report was no longer able to read the report selection form fields using request.form. Resetting the href value appears to redirect rather than refresh, losing that magical connection between browser windows that Old Pedant pointed out to me. And it can't build the report if I don't know what the user was looking for. I can't switch to GET because the amount of data passed between the pages exceeds the url maximum length (another unfortunate and arbitrary limitation, imho). Cookies have a similar limitation, and our server seems unable to hold onto sessions long enough to rely upon session variables.

Okay, in that case the only thing I can suggest is to store all the values that were sent in the post in the page. Then have a function that reposts this data to the server when you need to refresh the page.

--

Joe (Microsoft MVP - XML)

I considered that option, too. I would have to make some pretty significant changes to this program to do this, though, and I simply do not have the time to rewrite it. The half-assed work around will have to do.

Thanks!