469,326 Members | 1,415 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,326 developers. It's quick & easy.

response.writeLine

Hello,
How can I write a line (with carriage return + line feed) to the client ?
response.write("abcd"), continue the last line, and doesn't put cr+lf.
response.writeLn is illegal syntax...

Thank :)
Jul 22 '05 #1
35 32092
Response.Write("Abcd" & "<BR>")
--
Roji. P. Thomas
Net Asset Management
https://www.netassetmanagement.com
"Eitan" <no_spam_please@nospam_please.com> wrote in message
news:Ow****************@TK2MSFTNGP10.phx.gbl...
Hello,
How can I write a line (with carriage return + line feed) to the client ?
response.write("abcd"), continue the last line, and doesn't put cr+lf.
response.writeLn is illegal syntax...

Thank :)

Jul 22 '05 #2
Thanks :)

"Roji. P. Thomas" <th********@gmail.com> wrote in message
news:Oi****************@TK2MSFTNGP15.phx.gbl...
Response.Write("Abcd" & "<BR>")
--
Roji. P. Thomas
Net Asset Management
https://www.netassetmanagement.com
"Eitan" <no_spam_please@nospam_please.com> wrote in message
news:Ow****************@TK2MSFTNGP10.phx.gbl...
Hello,
How can I write a line (with carriage return + line feed) to the client ? response.write("abcd"), continue the last line, and doesn't put cr+lf.
response.writeLn is illegal syntax...

Thank :)


Jul 22 '05 #3
Roji. P. Thomas wrote on 12 jan 2005:
How can I write a line (with carriage return + line feed)?
Response.Write("Abcd" & "<BR>")

Preferably do not use () here in VBscript.
They are just an extra parsing step and
you will get an error doing the same
on a statement with more than one argument.

Response.Write "Abcd" & "<br>" & VbCrLf

the VbCrLf will get you a new line
in the rendered source on the client

Response.Write <p> & "Abcd" & "</p>" & VbCrLf

is the way to make paragraphs

etc.
--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

Jul 22 '05 #4
CJM
"Evertjan." <ex**************@interxnl.net> wrote in message
news:Xn********************@194.109.133.29...
Response.Write "Abcd" & "<br>" & VbCrLf

the VbCrLf will get you a new line
in the rendered source on the client


Do you know... for 5 years I've wanted know if we could do this, but I never
got around to asking!

lol

Cheers

Chris
Jul 22 '05 #5
"Evertjan." wrote in message news:Xn********************@194.109.133.29...
: Roji. P. Thomas wrote on 12 jan 2005:
:
: >> How can I write a line (with carriage return + line feed)?
:
: > Response.Write("Abcd" & "<BR>")
:
:
: Preferably do not use () here in VBscript.
: They are just an extra parsing step and
: you will get an error doing the same
: on a statement with more than one argument.
:
: Response.Write "Abcd" & "<br>" & VbCrLf
:
: the VbCrLf will get you a new line
: in the rendered source on the client
:
: Response.Write <p> & "Abcd" & "</p>" & VbCrLf
:
: is the way to make paragraphs

I use these 2 routines often... I never get an error.

sub prt(str)
Response.Write(str & vbCrLf)
end sub

sub lprt(str)
Response.Write(str & "<br />" & vbCrLf)
end sub

I routinely use it for debugging. I don't understand the multiple arguments
comment.

lprt("Count0: " & cnt0 & " records processed.")
lprt("Count1: " & cnt1 & " records processed.")
lprt("Count2: " & cnt2 & " records processed.")
lprt("Count3: " & cnt3 & " records processed.")
lprt("Count4: " & cnt4 & " records processed.")
lprt("Count5: " & cnt5 & " records processed.")
lprt("Count6: " & cnt6 & " records processed.")
lprt("Count7: " & cnt7 & " records processed.")
lprt("Count8: " & cnt8 & " records processed.")
lprt("Count9: " & cnt9 & " records processed.")
lprt("Checksum: " & (cnt0 + cnt1 + cnt2 + cnt3 + cnt4 + cnt5 + cnt6 + cnt7
+ cnt8 + cnt9))

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

Jul 22 '05 #6
Roland Hall wrote:

I use these 2 routines often... I never get an error.

sub prt(str)
Response.Write(str & vbCrLf)
end sub

sub lprt(str)
Response.Write(str & "<br />" & vbCrLf)
end sub

I routinely use it for debugging. I don't understand the multiple
arguments comment.

lprt("Count0: " & cnt0 & " records processed.")
lprt("Count1: " & cnt1 & " records processed.")
lprt("Count2: " & cnt2 & " records processed.")
lprt("Count3: " & cnt3 & " records processed.")
lprt("Count4: " & cnt4 & " records processed.")
lprt("Count5: " & cnt5 & " records processed.")
lprt("Count6: " & cnt6 & " records processed.")
lprt("Count7: " & cnt7 & " records processed.")
lprt("Count8: " & cnt8 & " records processed.")
lprt("Count9: " & cnt9 & " records processed.")
lprt("Checksum: " & (cnt0 + cnt1 + cnt2 + cnt3 + cnt4 + cnt5 + cnt6 +
cnt7 + cnt8 + cnt9))


In each of these cases, you are passing a single argument to the lprt sub.
The parentheses are forcing the argument to be passed by value instead of
byref, which means that a copy of the argument is created and passed to the
procedure (extra processing and memory utilization).

If a sub accepts multiple arguments, using parentheses will generate an
error when you call it:

sub foo(p1,p2)
....
end sub
foo("a","b")

Because in this case, the parentheses are trying to create a copy of the
single value expected to be contained within them. An error is thrown when
two values are present.
This would not cause an error:
foo("a"),("b")
Each argument is being passed by value

Neither would this:
foo "a","b"
Each argument is being passed by reference.

The same is true for functions where you don't "use" the value returned by
the function:

function bar(p1,p2)
bar=p1 + p2
end function

Causes error:
bar(2,3)

does not cause error:
bar (2),(3)
bar 2,3
a = bar(2,3)
if bar(2,3) = 5 then
a = bar((2),(3))
if bar((2),(3)) = 5 then
See here for more:
http://blogs.msdn.com/ericlippert/ar.../15/52996.aspx

Bob Barrows
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Jul 22 '05 #7
why so difficult???

response.write (str)%> <br> <% your code...
"Bob Barrows [MVP]" <re******@NOyahoo.SPAMcom> a écrit dans le message de
news: Oq**************@TK2MSFTNGP12.phx.gbl...
Roland Hall wrote:

I use these 2 routines often... I never get an error.

sub prt(str)
Response.Write(str & vbCrLf)
end sub

sub lprt(str)
Response.Write(str & "<br />" & vbCrLf)
end sub

I routinely use it for debugging. I don't understand the multiple
arguments comment.

lprt("Count0: " & cnt0 & " records processed.")
lprt("Count1: " & cnt1 & " records processed.")
lprt("Count2: " & cnt2 & " records processed.")
lprt("Count3: " & cnt3 & " records processed.")
lprt("Count4: " & cnt4 & " records processed.")
lprt("Count5: " & cnt5 & " records processed.")
lprt("Count6: " & cnt6 & " records processed.")
lprt("Count7: " & cnt7 & " records processed.")
lprt("Count8: " & cnt8 & " records processed.")
lprt("Count9: " & cnt9 & " records processed.")
lprt("Checksum: " & (cnt0 + cnt1 + cnt2 + cnt3 + cnt4 + cnt5 + cnt6 +
cnt7 + cnt8 + cnt9))
In each of these cases, you are passing a single argument to the lprt sub.
The parentheses are forcing the argument to be passed by value instead of
byref, which means that a copy of the argument is created and passed to

the procedure (extra processing and memory utilization).

If a sub accepts multiple arguments, using parentheses will generate an
error when you call it:

sub foo(p1,p2)
...
end sub
foo("a","b")

Because in this case, the parentheses are trying to create a copy of the
single value expected to be contained within them. An error is thrown when
two values are present.
This would not cause an error:
foo("a"),("b")
Each argument is being passed by value

Neither would this:
foo "a","b"
Each argument is being passed by reference.

The same is true for functions where you don't "use" the value returned by
the function:

function bar(p1,p2)
bar=p1 + p2
end function

Causes error:
bar(2,3)

does not cause error:
bar (2),(3)
bar 2,3
a = bar(2,3)
if bar(2,3) = 5 then
a = bar((2),(3))
if bar((2),(3)) = 5 then
See here for more:
http://blogs.msdn.com/ericlippert/ar.../15/52996.aspx

Bob Barrows
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

Jul 22 '05 #8
Bob Barrows [MVP] wrote:
If a sub accepts multiple arguments, using parentheses will generate
an error when you call it: ^^^^
I disagree.
foo("a","b")


That is not the only way to call a Sub. This is perfectly fine:

Call foo("a","b")

--
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. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 22 '05 #9
> response.write (str)%> <br> <% your code...

Thats just silly........... would be better to simply do;

response.write str & "<br>"

--

Regards

Steven Burn
Ur I.T. Mate Group
www.it-mate.co.uk

Keeping it FREE!

"eXistenZ|" <na****@hotmail.com> wrote in message
news:ON**************@TK2MSFTNGP10.phx.gbl...
why so difficult???

response.write (str)%> <br> <% your code...
"Bob Barrows [MVP]" <re******@NOyahoo.SPAMcom> a écrit dans le message de
news: Oq**************@TK2MSFTNGP12.phx.gbl...
Roland Hall wrote:

I use these 2 routines often... I never get an error.

sub prt(str)
Response.Write(str & vbCrLf)
end sub

sub lprt(str)
Response.Write(str & "<br />" & vbCrLf)
end sub

I routinely use it for debugging. I don't understand the multiple
arguments comment.

lprt("Count0: " & cnt0 & " records processed.")
lprt("Count1: " & cnt1 & " records processed.")
lprt("Count2: " & cnt2 & " records processed.")
lprt("Count3: " & cnt3 & " records processed.")
lprt("Count4: " & cnt4 & " records processed.")
lprt("Count5: " & cnt5 & " records processed.")
lprt("Count6: " & cnt6 & " records processed.")
lprt("Count7: " & cnt7 & " records processed.")
lprt("Count8: " & cnt8 & " records processed.")
lprt("Count9: " & cnt9 & " records processed.")
lprt("Checksum: " & (cnt0 + cnt1 + cnt2 + cnt3 + cnt4 + cnt5 + cnt6 +
cnt7 + cnt8 + cnt9))


In each of these cases, you are passing a single argument to the lprt sub. The parentheses are forcing the argument to be passed by value instead of byref, which means that a copy of the argument is created and passed to

the
procedure (extra processing and memory utilization).

If a sub accepts multiple arguments, using parentheses will generate an
error when you call it:

sub foo(p1,p2)
...
end sub
foo("a","b")

Because in this case, the parentheses are trying to create a copy of the
single value expected to be contained within them. An error is thrown when two values are present.
This would not cause an error:
foo("a"),("b")
Each argument is being passed by value

Neither would this:
foo "a","b"
Each argument is being passed by reference.

The same is true for functions where you don't "use" the value returned by the function:

function bar(p1,p2)
bar=p1 + p2
end function

Causes error:
bar(2,3)

does not cause error:
bar (2),(3)
bar 2,3
a = bar(2,3)
if bar(2,3) = 5 then
a = bar((2),(3))
if bar((2),(3)) = 5 then
See here for more:
http://blogs.msdn.com/ericlippert/ar.../15/52996.aspx

Bob Barrows
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"


Jul 22 '05 #10
Thanks for making that a bit more clear in my head, Bob.

Jim
"Bob Barrows [MVP]" <re******@NOyahoo.SPAMcom> wrote in message
news:Oq****************@TK2MSFTNGP12.phx.gbl...
Roland Hall wrote:

I use these 2 routines often... I never get an error.

sub prt(str)
Response.Write(str & vbCrLf)
end sub

sub lprt(str)
Response.Write(str & "<br />" & vbCrLf)
end sub

I routinely use it for debugging. I don't understand the multiple
arguments comment.

lprt("Count0: " & cnt0 & " records processed.")
lprt("Count1: " & cnt1 & " records processed.")
lprt("Count2: " & cnt2 & " records processed.")
lprt("Count3: " & cnt3 & " records processed.")
lprt("Count4: " & cnt4 & " records processed.")
lprt("Count5: " & cnt5 & " records processed.")
lprt("Count6: " & cnt6 & " records processed.")
lprt("Count7: " & cnt7 & " records processed.")
lprt("Count8: " & cnt8 & " records processed.")
lprt("Count9: " & cnt9 & " records processed.")
lprt("Checksum: " & (cnt0 + cnt1 + cnt2 + cnt3 + cnt4 + cnt5 + cnt6 +
cnt7 + cnt8 + cnt9))


In each of these cases, you are passing a single argument to the lprt sub.
The parentheses are forcing the argument to be passed by value instead of
byref, which means that a copy of the argument is created and passed to
the procedure (extra processing and memory utilization).

If a sub accepts multiple arguments, using parentheses will generate an
error when you call it:

sub foo(p1,p2)
...
end sub
foo("a","b")

Because in this case, the parentheses are trying to create a copy of the
single value expected to be contained within them. An error is thrown when
two values are present.
This would not cause an error:
foo("a"),("b")
Each argument is being passed by value

Neither would this:
foo "a","b"
Each argument is being passed by reference.

The same is true for functions where you don't "use" the value returned by
the function:

function bar(p1,p2)
bar=p1 + p2
end function

Causes error:
bar(2,3)

does not cause error:
bar (2),(3)
bar 2,3
a = bar(2,3)
if bar(2,3) = 5 then
a = bar((2),(3))
if bar((2),(3)) = 5 then
See here for more:
http://blogs.msdn.com/ericlippert/ar.../15/52996.aspx

Bob Barrows
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

Jul 22 '05 #11
eXistenZ| wrote:
why so difficult???

response.write (str)%> <br> <% your code...

What do you mean? What difficulty?

I was answering the question as to why parentheses should not be used there.
While I dislike the practice of intermingling server and client-side code,
this is more correct (and slightly more efficient):

response.write str%> <br> <% your code...

Bob Barrows

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Jul 22 '05 #12
Dave Anderson wrote:
Bob Barrows [MVP] wrote:
If a sub accepts multiple arguments, using parentheses will generate
an error when you call it:

^^^^
I disagree.
foo("a","b")


That is not the only way to call a Sub. This is perfectly fine:

Call foo("a","b")


Fine:

" ... when you call it without using the Call statement"

Better?

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Jul 22 '05 #13
Bob Barrows [MVP] wrote:
" ... when you call it without using the Call statement"

Better?


Sure. My observation was not offered merely for nit picking. I am curious to
know why Call is so overlooked in here. We use it as a shop standard
*because* it requires parentheses. Among other thins, this has the effect of
making Sub calls stand out visually.

This conversation has piqued my interest in one thing: Does the parentheses
= byref rule apply when using Call?
--
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. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 22 '05 #14
Dave Anderson wrote on 13 jan 2005 in
microsoft.public.inetserver.asp.general:
Sure. My observation was not offered merely for nit picking. I am
curious to know why Call is so overlooked in here. We use it as a shop
standard *because* it requires parentheses. Among other thins, this
has the effect of making Sub calls stand out visually.


Because of the sloppyness of M$ the difference
between a statement and a function call is blurred.

Every row in VBscript and earlier Basics is a statement.

There are two "default statements"

====================
1 the LET statement:

LET a = 1

[This should be different from the conditional
a = 1, which returns a boolean true/false,
and is used in Jscript as ==]

Nowadays [VBscript] only

a = 1 is used, a tutorial mistake.

====================
2 the statementized function

A function should be in an expression

a = 3 + myFunction

but if a function's return value is not used or not specified,
the function can or must be used as a statement or as a called [CALL]
funcion

======================
Statements never have parentheses around their parameters.
Functions always have, unless they are statementized.

======================

So the statmentized function:

myFunction "param1", "param2"

goes without parentheses,
but adding parameters around seperate expressions
is legal but silly, like:

myFunction ("param1"), ("param2")

That is why

Response.write ("Hello world")

Is also silly, useless, costs some extra processing
and is to be avoided for tutorial reasons,
because the error of

myFunction ("param1", "param2")

would not be avoided or understood.

========================

Using

Call myFunction ("param1", "param2")

is legal, but only for real functions
and not for statements.

Conclusion:

Never use:

Response.write ("Hello world")

or [also legal, but just as silly]:

Response.write (("Hello world"))

but always

Response.write "Hello world"

--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

Jul 22 '05 #15
Dave Anderson wrote:
Bob Barrows [MVP] wrote:
" ... when you call it without using the Call statement"

Better?
Sure. My observation was not offered merely for nit picking.


OK, I see that now. Sorry
I am
curious to know why Call is so overlooked in here. We use it as a
shop standard *because* it requires parentheses. Among other thins,
this has the effect of making Sub calls stand out visually.

I never use it. because I have an aversion to doing unnecessary typing. :-)
I can easily detect a Sub call (or a function called as if it was a sub) by
the absence of parentheses. But that's just because I'm used to doing it
this way.

So you use it only for Sub calls? How about functions that are being called
as if they were subs? I.E., calls where the return value is discarded
without being assigned to anything?

Do you also require it for calls to builtin methods being called as subs?
E.G., do you require

Call MsgBox("test")

as opposed to

MsgBox "test"

?
This conversation has piqued my interest in one thing: Does the
parentheses = byref rule apply when using Call?


I don't know. There's nothing in Eric's blog to suggest that there's any
difference, but I'm going to have to try it and see. Be right back ...

OK, using this code (in a vbscript file so I could use msgbox):
'************************************************* ***********
sub foo(p1)
p1=p1+5
end sub
dim i
i=5
msgbox i,,"Before sub call"
Call foo(i)
msgbox i,,"After sub call using Call - no extra parens"
Call foo((i))
msgbox i,,"After sub call using Call - with extra parens"

'************************************************* ***********

I got these messages:
5
10 - initial call passing byref
10 - second call proving that parens forced byval

So it appears that the behavior is the same when using Call.

I was also curious whether the parens would override the explicit use of
byref in the sub declaration statement (it was already clear that they had
no effect when byval was explicitly used in the sub statement), so I
modified my test sub to this:

sub foo( byref p1)
p1=p1+5
end sub

and discovered that the parens do indeed override the byref keyword in the
sub statement.
Bob Barrows
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Jul 22 '05 #16
"Bob Barrows [MVP]" wrote in message
news:uD****************@TK2MSFTNGP10.phx.gbl...
: Dave Anderson wrote:
: > Bob Barrows [MVP] wrote:
: >> " ... when you call it without using the Call statement"
: >>
: >> Better?
: >
: > Sure. My observation was not offered merely for nit picking.
:
: OK, I see that now. Sorry
:
: > I am
: > curious to know why Call is so overlooked in here. We use it as a
: > shop standard *because* it requires parentheses. Among other thins,
: > this has the effect of making Sub calls stand out visually.
: >
:
: I never use it. because I have an aversion to doing unnecessary typing.
:-)
: I can easily detect a Sub call (or a function called as if it was a sub)
by
: the absence of parentheses. But that's just because I'm used to doing it
: this way.
:
: So you use it only for Sub calls? How about functions that are being
called
: as if they were subs? I.E., calls where the return value is discarded
: without being assigned to anything?
:
: Do you also require it for calls to builtin methods being called as subs?
: E.G., do you require
:
: Call MsgBox("test")
:
: as opposed to
:
: MsgBox "test"
:
: ?
:
: > This conversation has piqued my interest in one thing: Does the
: > parentheses = byref rule apply when using Call?
:
: I don't know. There's nothing in Eric's blog to suggest that there's any
: difference, but I'm going to have to try it and see. Be right back ...

I thought there was even though it was used as a function.

3) Call a function or subroutine: Limit = UBound(MyArray)

and...

3.2) An argument list for a subroutine call (or a function call with no
assignment) that uses the Call keyword must be surrounded by parens: Call
MySub(MyArg)

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp
Jul 22 '05 #17
Roland Hall wrote:
"Bob Barrows [MVP]" wrote in message
news:uD****************@TK2MSFTNGP10.phx.gbl...
Dave Anderson wrote:
Bob Barrows [MVP] wrote:
" ... when you call it without using the Call statement"

Better?

Sure. My observation was not offered merely for nit picking.
OK, I see that now. Sorry
I am
curious to know why Call is so overlooked in here. We use it as a
shop standard *because* it requires parentheses. Among other thins,
this has the effect of making Sub calls stand out visually.
<snip> This conversation has piqued my interest in one thing: Does the
parentheses = byref rule apply when using Call?


I don't know. There's nothing in Eric's blog to suggest that there's
any difference, but I'm going to have to try it and see. Be right
back ...


I thought there was even though it was used as a function.

3) Call a function or subroutine: Limit = UBound(MyArray)


I don't understand the point: this line is not utilizing the Call statement
....

and...

3.2) An argument list for a subroutine call (or a function call with
no assignment) that uses the Call keyword must be surrounded by
parens: Call MySub(MyArg)


Right, but this is saying that the entire list of arguments must be
surrounded by one set of parentheses.

Call MySub(arg1, arg2,...argN)

What Dave is asking is whether surrounding each individual argument with
parentheses (in addition to the parens surrounding the entire argument):

Call MySub((arg1), (arg2),...argN)

would force the arguments to be passed byval, which my tests showed to be
the case.

Bob Barrows

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Jul 22 '05 #18
Evertjan. wrote:
Using

Call myFunction ("param1", "param2")

is legal, but only for real functions
and not for statements.
Wrong.

Call Statement
Transfers control to a Sub or Function procedure.

http://msdn.microsoft.com/library/en.../vsstmcall.asp
Never use:

Response.write ("Hello world")
I agree. You should use the proper case for [Write]. In any case, the
Response Object is not part of VBScript, and is therefore not subject to all
of VBScript's rules. Or VBScript at all, for that matter.

but always

Response.write "Hello world"


Wrong:

Microsoft JScript compilation error '800a03ec'
Expected ';'
/test.asp, line 1
Response.write "Hello World"
---------------^
Words like "always" are often misused.

--
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. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 22 '05 #19
Dave Anderson wrote on 13 jan 2005 in
microsoft.public.inetserver.asp.general:
Evertjan. wrote:
Using

Call myFunction ("param1", "param2")

is legal, but only for real functions
and not for statements.
Wrong.

Call Statement
Transfers control to a Sub or Function procedure.

http://msdn.microsoft.com/library/en.../vsstmcall.asp


True, also for sub's, but sub's are a not very different from functions
without a return value.

False, in the sense of my argument, that real statements, either native
VBscript or inherited from the Server object, cannot be called with
"call".
Never use:

Response.write ("Hello world")
I agree. You should use the proper case for [Write].


Why?
In any case, the
Response Object is not part of VBScript, and is therefore not subject
to all of VBScript's rules. Or VBScript at all, for that matter.
see above.
but always

Response.write "Hello world"


Wrong:

Microsoft JScript compilation error '800a03ec'
Expected ';'
/test.asp, line 1
Response.write "Hello World"
---------------^


Not in my posting, as I was talking about ASP-VBscript.

btw, also not in Forth, where it is simply:

.." Hello World"
Words like "always" are often misused.


May very well be generalizing, but not in my posting, as I was talking
about VBscript.
--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

Jul 22 '05 #20
"Bob Barrows [MVP]" wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl...
: Roland Hall wrote:
: > "Bob Barrows [MVP]" wrote in message
: > news:uD****************@TK2MSFTNGP10.phx.gbl...
: >> Dave Anderson wrote:
: >>> Bob Barrows [MVP] wrote:
: >>>> " ... when you call it without using the Call statement"
: >>>>
: >>>> Better?
: >>>
: >>> Sure. My observation was not offered merely for nit picking.
: >>
: >> OK, I see that now. Sorry
: >>
: >>> I am
: >>> curious to know why Call is so overlooked in here. We use it as a
: >>> shop standard *because* it requires parentheses. Among other thins,
: >>> this has the effect of making Sub calls stand out visually.
: >>>
: <snip>
: >>> This conversation has piqued my interest in one thing: Does the
: >>> parentheses = byref rule apply when using Call?
: >>
: >> I don't know. There's nothing in Eric's blog to suggest that there's
: >> any difference, but I'm going to have to try it and see. Be right
: >> back ...
: >
: > I thought there was even though it was used as a function.
: >
: > 3) Call a function or subroutine: Limit = UBound(MyArray)
:
: I don't understand the point: this line is not utilizing the Call
statement

This line was presented in reference to this question:
Do you also require it for calls to builtin methods being called as subs?

: > 3.2) An argument list for a subroutine call (or a function call with
: > no assignment) that uses the Call keyword must be surrounded by
: > parens: Call MySub(MyArg)
:
: Right, but this is saying that the entire list of arguments must be
: surrounded by one set of parentheses.
:
: Call MySub(arg1, arg2,...argN)
:
: What Dave is asking is whether surrounding each individual argument with
: parentheses (in addition to the parens surrounding the entire argument):
:
: Call MySub((arg1), (arg2),...argN)
:
: would force the arguments to be passed byval, which my tests showed to be
: the case.

Well, then I misunderstood the question. I thought he was referring to
functions requiring parens when being called byref, not byval as they relate
to builtin methods.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp
Jul 22 '05 #21
Roland Hall wrote:
> I am
> curious to know why Call is so overlooked in here. We use it as a
> shop standard *because* it requires parentheses. Among other
> thins, this has the effect of making Sub calls stand out visually.
>
3) Call a function or subroutine: Limit = UBound(MyArray)


I don't understand the point: this line is not utilizing the Call
statement


This line was presented in reference to this question:
Do you also require it for calls to builtin methods being called as
subs?


Oh, OK. But I'm still puzzled. How does quoting a line from Eric's blog
answer the question I directed to Dave about his "shop standards"?

Oh! Wait, I see. My questions weren't clear. You thought I was asking a more
"generic" question. Never mind.

Bob Barrows
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Jul 22 '05 #22
Bob Barrows [MVP] wrote:
I never use it. because I have an aversion to doing unnecessary
typing. :-)
I would find that easier to believe if you also confessed that you prefer
JScript to VBScript.

So you use it only for Sub calls? How about functions that are being
called as if they were subs? I.E., calls where the return value is
discarded without being assigned to anything?
I'm not sure I follow. Why would I return a value and not use it
(alternately - why would I use a Function to do a Sub's job)? I guess my
answer is yes, but vacuously. We always use parentheses for Function and Sub
calls, utilizing the Call keyword when neccessary.

Do you also require it for calls to builtin methods being called as
subs? E.G., do you require

Call MsgBox("test")

as opposed to

MsgBox "test"
The only built-in *Functions* I know of that do not return values are MsgBox
and InputBox, neither of which I use (and could not use in ASP anyway). In
every other case I can think of, I am calling the Function in order to use
the return value, so the Call keyword could not possibly apply.

As for VBScript Methods, if they do not return a value, then yes:

Call Err.Clear()
...So it appears that the behavior is the same when using Call.
That's interesting -- and the preferred behavior, IMO.
...the parens do indeed override the byref keyword
in the sub statement.


Also interesting. Also preferred.

--
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. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 22 '05 #23
Dave Anderson wrote:
Bob Barrows [MVP] wrote:
I never use it. because I have an aversion to doing unnecessary
typing. :-)
I would find that easier to believe if you also confessed that you
prefer JScript to VBScript.


Frankly, I find that Jscript forces more typing on me, but that's IMO, of
course. Of course, one of the reasons for this opinion is the intellisense
and autocomplete features in vi6. Forced to use another tool, I might change
my opinion.

I still find vbscript much easier to read and follow that jscript. I know
that the "End If"s etc are a source of derision among non-vb pundits, but I
find it easier to discern the end of nested blocks when reading vbscript as
opposed to:

.....
}
}
}

Of course there are exceptions (similar types of nested blocks are
problematic in vbscript as well as jscript)

But I'm sure this perceived difficulty will be diminished by usage.

So you use it only for Sub calls? How about functions that are being
called as if they were subs? I.E., calls where the return value is
discarded without being assigned to anything?
I'm not sure I follow. Why would I return a value and not use it
(alternately - why would I use a Function to do a Sub's job)?


For the same reason that MS wrote msgbox the way they did... Why have two
methods that do the same thing? The user has the choice to use, or not use,
the returned value.
I guess
my answer is yes, but vacuously. We always use parentheses for
Function and Sub calls, utilizing the Call keyword when neccessary.

Do you also require it for calls to builtin methods being called as
subs? E.G., do you require

Call MsgBox("test")

as opposed to

MsgBox "test"


The only built-in *Functions* I know of that do not return values are

Huh? MsgBox is a builtin method that can be called as either a function
(when not discarding the returned value):

if msgbox("Yes or No?",vbyesno) then

or a sub

msgbox "test"

But I guess you've answered my question. You would use Call for the latter.

Bob

PS. Oh, wait. I see you point. Yes, MsgBox and InputBox are functions.
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Jul 22 '05 #24
Evertjan. wrote:
Call Statement
Transfers control to a Sub or Function procedure.

http://msdn.microsoft.com/library/en.../vsstmcall.asp
True, also for sub's, but sub's are a not very different from
functions without a return value.


Except, as Bob points alludes, that they require less typing. To put this
back into context, retrace the thread to this Bob Barrows posting:
>>>> If a sub accepts multiple arguments, using parentheses
>>>> will generate an error when you call it:
That was the whole point of bringing up the Call Statement.
False, in the sense of my argument, that real statements, either
native VBscript or inherited from the Server object, cannot be called
with "call".
I was rebutting this: "only for real functions". Is a Sub a real Function?
No - it does not return a value. Yet it can be called with parentheses.
I agree. You should use the proper case for [Write].


Why?


Correctness is reason enough for proper capitalization. Call it "respect for
the reader" if you prefer.
Microsoft JScript compilation error '800a03ec'
Expected ';'
/test.asp, line 1
Response.write "Hello World"
---------------^


Not in my posting, as I was talking about ASP-VBscript.


Again, let's put it back into context. Your
Conclusion:
Never use:
Response.write ("Hello world")


was incorrectly based on inferences to VBScript Sub and Function handling. I
reiterate: The Response Object has nothing to do with VBScript whatsoever.
Nor JScript. It is an object exposed to the scripting engine, and its
behavior accordingly follows different rules altogether.

Note that all of these are legal:

VBScript ====================
Response.Write "Hello World"
Response.Write("Hello World")
Call Response.Write("Hello World")

JScript ====================
Response.Write("Hello World")
Response.write("Hello World")
Response.WrItE("Hello World")

Note that JScript requires proper case for the Response Object, but not for
its methods. This diverges from the JScript behavior with native JScript
objects.
May very well be generalizing, but not in my posting, as I
was talking about VBscript.


Once you used the Response Object, you were outside VBScript.

--
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. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 22 '05 #25
Bob Barrows [MVP] wrote:
Frankly, I find that Jscript forces more typing on me, but that's
IMO, of course. Of course, one of the reasons for this opinion is the
intellisense and autocomplete features in vi6. Forced to use another
tool, I might change my opinion.
I'm not sure I understand this, as VI6 has intellisense in JScript as
well...
But I'm sure this perceived difficulty will be diminished by usage.


Agreed.

--
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. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 22 '05 #26
Dave Anderson wrote on 14 jan 2005 in
microsoft.public.inetserver.asp.general:
VBScript ====================
Response.Write "Hello World"
Response.Write("Hello World")
Call Response.Write("Hello World")
You forget that also legal here is:

Response.Write (("Hello World"))

Response.Write ((("Hello World")))

and

x = (("Hello World")):RespoNSe.wriTE x

Once you used the Response Object, you were outside VBScript.


No Dave, you are not, with regard to the working of the argument.

The argument of Response.Write is processed by vbscript.

The argument of Response.Write in vbscript is x as in:

Response.Write x

Making the argument x an unneccessary complex expression
is perfectly legal end perfectly silly.


--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

Jul 22 '05 #27
Evertjan. wrote:
VBScript ====================
Response.Write "Hello World"
Response.Write("Hello World")
Call Response.Write("Hello World")


You forget that also legal here is:

Response.Write (("Hello World"))

Response.Write ((("Hello World")))

and

x = (("Hello World")):RespoNSe.wriTE x


You have completely missed the point. A native VBScript Function or Sub does
NOT produce the same behavior as the methods of the Response Object. To see
what I mean, consider the following:

Sub Output(x)
Response.Write(x)
End Sub

You cannot call this all three ways you can call the Write method of the
Response Object:

Output "Hello World" ' OK
Output("Hello World") ' Fails
Call Output("Hello World") ' OK

The reason you *CAN* with Response.Write is that the Response Object is not
part of VBScript. Until you understand that, there is no point in continuing
this discussion.
--
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. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 22 '05 #28
Dave Anderson wrote on 15 jan 2005 in
microsoft.public.inetserver.asp.general:
You have completely missed the point. A native VBScript Function or
Sub does NOT produce the same behavior as the methods of the Response
Object. To see what I mean, consider the following:
"The" point is nice, since my point was NOT to have () around arguments
of statements or functions used as statements. Native or not was only
your point.
Sub Output(x)
Response.Write(x)
End Sub

You cannot call this all three ways you can call the Write method of
the Response Object:

Output "Hello World" ' OK
Output("Hello World") ' Fails
Call Output("Hello World") ' OK
On my system [XPpro] this works fine:

<%
Output "1"
Output("2")
Call Output("3")

sub output(x)
response.write x
end sub
%>

returns: 123
The reason you *CAN* with Response.Write is that the Response Object
is not part of VBScript.
As tested above, you must be in error.
Until you understand that, there is no point
in continuing this discussion.


Why?
Just the opposite:
Having a discussion while agreeing on everything seems pointless to me.
Remember you came up with this point answering me in this
discussion/thread, and if you don't like it, you are off course free not
to answer.

But I don't accept you setting conditions for me, irrespective if you are
in error or not [even though you are incidentally]

--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

Jul 22 '05 #29
Evertjan. wrote:
"The" point is nice, since my point was NOT to have () around
arguments of statements or functions used as statements. Native or
not was only your point.


Allow me to respond to this in a moment.
The reason you *CAN* with Response.Write is that the Response Object
is not part of VBScript.


As tested above, you must be in error.


I was in error. The point WRT JScript stands on its own merits, however. The
behavior transcends the language because the object is not part of the
language.

Back to VBScript and Response.Write(). I regret that response, as my memory
was obviously no substitute for testing code.

Your point may indeed have been avoiding parentheses in VBScript, and that's
a perfectly acceptible point upon which to differ. In this case, I disagree
with you. I personally think the presence of parentheses makes code more
readable. That this happens to be our shop standard strongly suggests to me
that I am not the only one.

--
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. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 22 '05 #30
Dave Anderson wrote on 20 jan 2005 in
microsoft.public.inetserver.asp.general:
Your point may indeed have been avoiding parentheses in VBScript, and
that's a perfectly acceptible point upon which to differ. In this
case, I disagree with you. I personally think the presence of
parentheses makes code more readable.
That is not a subtitute for a principally wrong suggestion that is given by
this habit, that the parentheses are part of the [pseudo] statement, as
they are only a complicated way of describing the parameter expression.

I hope you agree this wrong suggestion is a bad thing in a tutorial
environment, such as this NG.

I your production environment, next to the inevitable extra cpu cycles
introduced in a scripting/interpreting sense [perhaps the parentheses are
deleted by optimizing compiler code?]
That this happens to be our shop
standard strongly suggests to me that I am not the only one.


It only suggests to me this shop standard is not educational for new
programmers. Shop standards are no proof of correctnes as such.

--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

Jul 22 '05 #31
Evertjan. wrote:
That is not a subtitute for a principally wrong suggestion that is
given by this habit, that the parentheses are part of the [pseudo]
statement, as they are only a complicated way of describing the
parameter expression.
The parentheses are not superfluous. The Call Statement makes them
*required*. As the Call Statement is part of the Language, it isn't
pseudo-anything.

I your production environment, next to the inevitable extra cpu cycles
introduced in a scripting/interpreting sense [perhaps the parentheses
are deleted by optimizing compiler code?]


This is a fictional concern. There are plenty of good practices that consume
CPU cycles. That does not make them bad practices. CPU cycles are cheap
compared to developer hours.

Following your line of reasoning, we should not use indentation or comments,
since they consume disk space. Good heavens.
--
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. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 22 '05 #32
Dave Anderson wrote on 21 jan 2005 in
microsoft.public.inetserver.asp.general:
Evertjan. wrote:
That is not a subtitute for a principally wrong suggestion that is
given by this habit, that the parentheses are part of the [pseudo]
statement, as they are only a complicated way of describing the
parameter expression.
The parentheses are not superfluous. The Call Statement makes them
*required*. As the Call Statement is part of the Language, it isn't
pseudo-anything.


No, you are not listening to my argument:

The call statement makes it a [pseudo]function or [pseudo]sub, where it
must adhere to the rules of the use of a function/sub.

The [pseudo]statement should adhere to the statement rules, certainly in
an tutorial sense.

if you use [using two vbscript external examples]:

Response.Write("hello world")

it would be reasonable to use:

Conn.Execute(SQLstring , , 1)

and not understand the generated error.
I your production environment, next to the inevitable extra cpu
cycles introduced in a scripting/interpreting sense [perhaps the
parentheses are deleted by optimizing compiler code?]


This is a fictional concern. There are plenty of good practices that
consume CPU cycles. That does not make them bad practices. CPU cycles
are cheap compared to developer hours.


Certainly, but using extra cpu cycles for a bad habit only makes it a
slightly worse habit.
Following your line of reasoning, we should not use indentation or
comments, since they consume disk space. Good heavens.


In this NG the concern should not be being in cyberheaven, but in showing
the way to sound coding heaven.

Introdusing the above error by association,
like using Conn.Execute(SQLstring , , 1),
ia not showing the right direction.

--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

Jul 22 '05 #33
Evertjan. wrote:
The call statement makes it a [pseudo]function or [pseudo]sub, where
it must adhere to the rules of the use of a function/sub.
You can't use the Call statement unless it *IS* a function or sub[1]. What
on earth is your distinction? All you have contrived is a pseudo-name for
something that already has a name.
if you use [using two vbscript external examples]:

Response.Write("hello world")

it would be reasonable to use:

Conn.Execute(SQLstring , , 1)

and not understand the generated error.
Just as this:

RS = Conn.Execute(SQLString)

could lead to the belief that this is reasonable:

Conn.Execute(SQLString)

As with any language, OF COURSE you need to learn the rules. But please
don't pretend that the above won't generate a perfectly understandable error
message. Are you claiming you have never used (or failed to use) parentheses
ever?

Perhaps you are claiming that the "Cannot use parentheses when calling a
Sub" error message has proved too difficult for you to overcome, and by
extension, so it must be for the rest of the world. In that case, I concede
the point.
In this NG the concern should not be being in cyberheaven, but in
showing the way to sound coding heaven.
Sound coding is much more than CPU cycles. If "no parentheses" were such a
great idea to begin with, don't you suppose it would have carried over to
VB.NET?
Introdusing the above error by association,
like using Conn.Execute(SQLstring , , 1),
ia not showing the right direction.


Let's get this straight. Calling a sub with parentheses without using the
Call Statement causes an error. We all know that. But you have done nothing
to show that one solution (learning to use the Call Statement) introduces
more coding errors than another (learning to leave off parentheses).

[1] If you want to play semantics and charge that method is neither, fine.
But as with Functions and Subs, the rules are the same. You can use the Call
Statement (or assignment) together with parentheses, or omit both.
--
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. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 22 '05 #34
Dave Anderson wrote on 21 jan 2005 in
microsoft.public.inetserver.asp.general:
The call statement makes it a [pseudo]function or [pseudo]sub, where
it must adhere to the rules of the use of a function/sub.


You can't use the Call statement unless it *IS* a function or sub[1].
What on earth is your distinction? All you have contrived is a
pseudo-name for something that already has a name.


Since you don't seem to know what a statement is, and what a function, I
won't cover the rest of your response.

A statement in Basic dialects is a command.
It has to start on a new logical code line.
No code execution is possible without a statement.
A statement cannot return anything.
A new code line can only start with (1) a statement
or (2) a default statement
or (3) be empty.

[The remark statement Rem or ' is just a statement.]
[A line can contain several logical lines separated with a colon [:].
Modern Basics, like vbScript have two default statements:

1 the Let [=asignment] statement has been THE default statement for so
long, that the "let" in itself is no logger available. However theValue =
17 is not a statement by itself in Basic terms, because the underlying
asignment code is that belonging to the original let-statement.

2 The statementized function or sub. This is a defaulting of the call
statement, where the function/sub aquires the habits of a statement,
which I call [pseudo]statement, because it is realy a function/sub.

A function in sensu originalis has to return a value, and could at first,
in historical basic sense, only be used in an expression. A sub
[subroutine] was necessary for callable routines, not having a result.
These subroutines and functuons, not being statements, needed the call
statement for execution [outside an expresion in the case of a function].

An expression, btw, is a string of code that can be parced for a result
value.

========================================

Hereby I rest my case, not wanting to take more time explaining the
principles of basic Basic syntax to you.

Dave, I will not answer a possible reply.

--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

Jul 22 '05 #35
Evertjan. wrote:
The call statement makes it a [pseudo]function or [pseudo]sub, where
it must adhere to the rules of the use of a function/sub.


You can't use the Call statement unless it *IS* a function or sub[1].
What on earth is your distinction? All you have contrived is a
pseudo-name for something that already has a name.


Since you don't seem to know what a statement is, and what a
function, I won't cover the rest of your response.


You appear to be confusing my use of the term "Call Statement" with some
assertion that I am advocating "calling a statement". You are wrong. I am
using it exactly as Microsoft does:
http://msdn.microsoft.com/library/en.../vsstmcall.asp

Given that */CORRECT/* context, the rest of your post makes no sense, as
yours depends on misinterpreting mine.
--
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. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 22 '05 #36

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.