ASp and HTML Execution Sequence

[gorilla1]

If a script outputs html at its beginning that has a meta refresh with a 0 second wait that transfers control to another page, and then there is quite a bit of additional asp code after that point within that first asp script, will all the asp code execute? Or is there any chance some of it will not?

G

[raf]

If you want to prevent html (a response) from beeing send to the client, just include
<% Response.Buffer = True %>
on top of your page. This will buffer all output, until the parser encounters a
Response.Flush or Response.End

Then all output will be send to the client.

But i really don't get what you're trying to do. (as in your other thread. But i'm probably just stupid.). You're redirecting clientsided (using javascript), but you can just as well do this serversided.
:confused:

[gorilla1]

Thanks Raf. Yes, this is a continuation of the other problem I was trying to solve. I have an order form handler called from many, many places. Folks were apparently hitting refresh on it so that I got duplciate orders. I could not do the session variable check or some of the other approaches you suggested, for various reasons. One element is that I don't know where control should return, other than from the referer address (since many places call this form handler). So I reached this solution: The order form routine has a metarefresh so that it immediately bounces the viewer back to the page that called it (ie where the form input was done). It also contains the asp code that has the form handling logic - enter in dtabase, etc. And it also now builds a javascript popup that shows what the customer entered on the form - ie the confirmation. So the viewer enters the order and next thing seen is this popup confirming what was entered - hitting refresh there will not cause a dulpicate order. What if viewer has javascript disabled? Well, I left the old code intact under a noscript portion of the routine and added there some protections - so there is still some window for a duplicate if they have javascript turned off, but I can live with that... So my concern is simply whether I can be sure all the asp code will execute, even though control is being immediately passed elsewhere.
... As far as why not redirect server side - the client side approach means I can elegantly return to the right calling routine without passing addresses and all the form fields from routine to routine, and I can also output the confrimation info on a page where there is absolutely no risk that a back or refresh button will cause a duplicate entry. Generally, I do all work server side and avoid popups like the plague, but it seemed like a better solution in this case, given the constraints I faced.
G

[raf]

Hmm. I kinda get the picture but not your logic/situation. But you'll know what you're doing. Anyway, setting the response.buffer = true will garanty that all code is executed (until the parser reaches a response.end or response.flush)

(but i'm still wondering if a multi purpose page (= form posting to itself) with the formhandler in an include and setting a flag after the form was processed, wouldn't do the trick. (Or just have some identificationvalue added to the querystring when the form is posted, and then have a redirect based on this identifier))

[gorilla1]

Raf,

Agreed, those are far preferable approaches. But what I have inherited is a complex of sites with literally hundreds of pages with forms on them that all call this one form processing routine. The sites are built with a very complex folder structure. Finding all the calls to this form processing routine and changing all of them would be a very large job, and the chances of missing a routine or two would be decent. So that is why I am attempting to work strictly within the confines of the form processing routine itself.

G