how to return value from server.execute call

[Dave Anderson]

Re: how to return value from server.execute call

"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.]

Re: how to return value from server.execute call

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]

Re: how to return value from server.execute call

"Jim Rodgers" <JimRodgers@dis cussions.micros oft.comwrote in message
news:C8949FD1-CEF4-4668-BBCC-B44F5EF59502@mi crosoft.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