how to return value from server.execute call

[=?Utf-8?B?SmltIFJvZGdlcnM=?=]

I am trying to replace a huge chunck of code that currently I incorporate
with an #Include directive. The program rarely has to flow through that
code, so I thought it would be better if I used Server.Execute.

I found I can pass data TO the called asp file by creating an HTML <input>
and erading it after I get there.

However, I also need to read back ONE variable that the called file must
set. I cannot figuer out how to do that. My backup positions are (1) I can
keep on using the #Include technique, and (2) I can use a database to bridge
the gap.

BUT... Isn't there a way to carry data BACK TO the calling asp file FROM
THE CALLED asp file?

I certainly do appreciate the help!

Thanks,

Jim

[Jon Paal [MSMD]]

you are correct..

[Jon Paal [MSMD]]

my bad, all page scope variables are not handled, see Dave's comment below.

[Evertjan.]

Jon Paal [MSMD] wrote on 06 aug 2007 in
microsoft.publi c.inetserver.as p.general:

my bad, all page scope variables are not handled, see Dave's comment
below.

Jon, what are you refering to?
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Evertjan.]

Jon Paal [MSMD] wrote on 06 aug 2007 in
microsoft.publi c.inetserver.as p.general:

you are correct..

Jon, what and who are you referring to?
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Dave Anderson]

"Evertjan." wrote:

>you are correct..

Jon, what and who are you referring to?

Me. And my post about what *IS* shared among scripts when Server.Execute( )
is used.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

[Dave Anderson]

"Evertjan." wrote:

>my bad, all page scope variables are not handled, see Dave's
comment below.

Jon, what are you refering to?

Evertjan, you really ought to give it a rest. I may be your only defender in
here, and even I tire of the constant policing.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

[Evertjan.]

Dave Anderson wrote on 06 aug 2007 in
microsoft.publi c.inetserver.as p.general:

"Evertjan." wrote:

>>my bad, all page scope variables are not handled, see Dave's
comment below.

Jon, what are you refering to?

Evertjan, you really ought to give it a rest. I may be your only
defender in here, and even I tire of the constant policing.

Dave, I think this is nonsense. Why even you?
I am just asking. If you think that is policing, so be it.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Anthony Jones]

"Jim Rodgers" <Ji********@dis cussions.micros oft.comwrote in message
news:C8******** *************** ***********@mic rosoft.com...

"Anthony Jones" wrote:

For this scenario the next step from an include file is a VB6 dll. Of
course for various reasons that may not be an option.

For an include file that contains a large set of functions enclosing

them in

a class helps to keep the global namespace free.

Server.Execute is not an appropriate solution.

How have you determined that having a large include file is a problem?

--
Anthony Jones - MVP ASP/ASP.NET

Thanks, Anthony!

I have not yet determined that having a large include file is a problem.

I

may keep what I have until it is a problem. However, I am not only

creating

a specific web application, but I am trying to keep my options open for

code

reuse since the project is turning into a decent platform for more work.

Your idea about a VB6 DLL is excellent. I am planning to replace a lot of
my #Includes (containing my VBScript Subs and Functions "library") with a

DLL

soon. But it will make more sense to you and everyone if I mention one

more

aspect of the problem I have in the current case.

The subject asp file (which currently is #Included and which I would

prefer

to be Server.Execute' d) processes a huge number of Request.Form(i)

variables

for all kinds of input validation requirements. It is because of the
Request.Form(i) variables that I felt Server.Execute would be a good

choice.

I hate having to pass all these TO the CALLED file.

What can't the function you call get the form values from the Request
object?

Since no one could tell me about [an obscure] technique for getting one or
two answers back to the CALLING script, I have decided to write the
validation results to a database. Thus, I need only to check the database
when I return to the first file. Previously, I acted on the validation
results (with Response.Write' s) in the CALLED file. Now I will simply do
that after I return. Even though the second file now does no output to

the

client side, it still makes sense to use Server.Execute because of the

sheer

volume of Request.Form(i) variables.

Would you agree?

No. The volume of values is not a problem there are numerous solutions to
this.

The appropriate approach is a function call and/or the use of Classes.

The fact that you need to jump through ugly hoops to attempt to force a
server.execute into a function call semantic (ie you want it to return a
value) indicates that it's not the right tool for the job.

--
Anthony Jones - MVP ASP/ASP.NET