ASP 3.0 - Server.Execute Problems: Suffering from "ASP Amnesia"

Created Two ASP 3.0 Files: -Main.asp -Colors.asp

Main.asp

<%

Blah Blah Blah...

If sColor = true then
Server.Execute "Colors.asp"
End If
'If sColor is tru开发者_Go百科e, Pops over to Colors.asp
'Then pops right back over to here again

'Once back here again, it has no idea what
'sRed or sBlue was at all...it's as if has
'been "blank slated"...sRed? Who the heck is sRed?

If sRed then
Response.Write "Color is Red"
End If
'Does not work...skips right over...
'Who is sRed? What is sRed?
'Oh well, keep on truckin'

%>

Colors.asp

<%
Dim sRed
sRed = instr(sString, "Red") >0

Dim sBlue
sBlue = instr(sString, "Blue") >0

Dim sGreen
sGreen = instr(sString, "Green") >0

%>

If one were to go into the Colors.asp file above and modify/append it to read as follows:

<%
Dim sRed
sRed = instr(sString, "Red") >0

Dim sBlue
sBlue = instr(sString, "Blue") >0

Dim sGreen
sGreen = instr(sString, "Green") >0

If sRed then
Response.Write "Color is Red"
End If

%>

One would receive a screen with "Color is Red" when sColor was true over at Main.asp and sString contained "Red." So I know she's getting over there, and also returning back over to Main.asp...but somehow she has no clue about those variables: sRed, sBlue, or sGreen that were dimmed over at Colors.asp.Once she get's back over to Main.asp she's clueless.

What gives? Why does she have ASP Amnesia once she gets back to Main.asp after having just been over at Colors.asp?

BTW, I used to have a girlfriend that acted the same way. So what kinda ASP hanky panky's goin' on over at Colors.asp?

Please help!

ASP Pee-Wee

The executed page has no access to local variables in the calling page and conversely neither does the calling page have access to local variables in the executed page. Whether you declare them or not makes no difference the two scripts are not executing in the same context let alone the same scope.

Calling Server.Execute() effectively causes the executed page to be executed in isolation and its output incorporated into the output of the calling page at the point it is called:

After IIS processes the .asp file specified in the input parameter to Server.Execute, the response is returned to the calling ASP script.

The following collections and properties are available to the executed ASP page:

* Application variables, even if they are set in the calling page.
* Session properties, even if they are set in the calling page.
* Server variables and properties, even if they are set in the calling page.
* Request collections and properties, even if they are set in the calling page. This includes Form and QueryString data passed to the calling page.
* Response collections and properties. The executed .asp file may modify HTTP headers. However, as with any .asp file, if the executed .asp file attempts to modify HTTP headers after it sends a response to the client, it generates an error.

If a file is included in the calling page by using #include, the executed .asp will not use it. For example, you may have a subroutine in a file that is included in your calling page, but the executed .asp will not recognize the subroutine name. You must include the file in each executed .asp that requires the subroutine.

If you want to do variable passing between scripts you are much better off using include directives. If you must do variable passing then you will have to jury rig something using the Application or Session object and I would not advise that.

The documentation (http://msdn.microsoft.com/en-us/library/ms525849(v=vs.90).aspx) says :

The Execute method calls an .asp file, and processes it as if it were part of the calling ASP script. The Execute method is similar to a procedure call in many programming languages.

If it's similar to a procedure call I guess it makes sense to scope the variables too. As was said by Dee, declare the variables in the calling page and it should work.

you probably need to dim the variables in the calling page (?)