response.writeLine

[Eitan]

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

 

[Roji. P. Thomas]

Response.Write("Abcd" & "<BR>")

 

[Eitan]

Thanks

Response.Write("Abcd" & "<BR>")

 

[Evertjan.]

Roji. P. Thomas wrote on 12 jan 2005:

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.

 

[CJM]

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

 

[Roland Hall]

in message : 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

 

[Bob Barrows [MVP]]

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/archive/2003/09/15/52996.aspx

Bob Barrows

 

[eXistenZ|]

why so difficult???

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

 

[Dave Anderson]

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.

 

[Steven Burn]

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!

 

[Jim in Arizona]

Thanks for making that a bit more clear in my head, Bob.

Jim

 

[Bob Barrows [MVP]]

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

 

[Bob Barrows [MVP]]

^^^^
I disagree.


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?

 

[Dave Anderson]

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

 

[Evertjan.]

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"

 

[Bob Barrows [MVP]]

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

 

[Roland Hall]

in message
: 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

 

[Bob Barrows [MVP]]

in message


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

 

[Dave Anderson]

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-us/script56/html/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.

 

[Evertjan.]

Dave Anderson wrote on 13 jan 2005 in
microsoft.public.inetserver.asp.general:

Wrong.

Call Statement
Transfers control to a Sub or Function procedure.

http://msdn.microsoft.com/library/en-us/script56/html/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.

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.