Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > microsoft.public.scripting.vbscript > #11196
| From | "R.Wieser" <address@not.available> |
|---|---|
| Newsgroups | microsoft.public.scripting.vbscript |
| Subject | Re: Weird bug |
| Date | 2015-11-17 17:13 +0100 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <n2fjn0$uu9$1@speranza.aioe.org> (permalink) |
| References | <n2d78f$639$1@dont-email.me> <n2esui$616$1@speranza.aioe.org> <n2fc8p$aal$1@dont-email.me> |
Mayayana,
> I don't know how you can say that's not a line:
Thats easy to explain: I never said that.
What I however *did* say that, as you have quoted in your message, "You
would not be able to write a one-line multy-command *THEN*" ....
And yes, your example is a single-line containing multiple commands
(assignments actually). But it also has got *nothing* to do with your
stated problem, the (as far as you think) quirks of the "if" command ...
> A colon acts as a line break.
Nope, it does not. The line break also has another function, namely the
termination of an(y) open "if" (in the case the "then" is, on the same line,
followed with more code).
> 'Include multiple statements in the statement argument,
> using colons or embedded line breaks to separate them.'
In itself that is correct. But I think you know as well as I that that is
not the full documentation about the language, and that several commands
mention their own exceptions to it.
> Here's another sample that works perfectly well:
And alas, again having nothing to do with the "if" command, and how it alter
the flow of the program. As is your "whole script in a single line." :-(
> Thus, the colon is acting as a line return.
Only if you ignore the line returns other effects, which your example code
does not make any use of.
> That's disconcerting, as I've been using colons for years.
Obviously not in VB6 .... :-D
> The point is simply that the design is a "gotcha".
Only if you tried to use this design when having used another design first.
Would you have used this design first the other design would have the
gotcha.
To quote myself:
<quote>
Suggestion: Do not try to take a feature of one programming
language and expect another one to adhere to it. Each language
"does its own thing". No ammount of "yes but ...." will
change anything to that I'm afraid.
</quote>
(typo fixed: "on one" -> "of one". Also left out a bracketed sub-sentence)
> For me the issue here is not what's officially correct or who's right
Than please don't try to create a problem where there is none. Its just a
difference in what you think is true (how something should work), and what a
programming/scripting language has been defined to how it works.
But a question: Have you already thought about the problem I described in my
initial reply, where I wanted to set both "X" and "Y" to zero when a
condition was met ?
How would you, using your approach, set that "Y" to zero ? -- without
turning the "if" in a multi-line construction ofcourse.
Maybe the designer of the programming language saw something you (still)
have not .... :-)
Regards,
Rudy Wieser
-- Origional message
Mayayana <mayayana@invalid.nospam> schreef in berichtnieuws
n2fc8p$aal$1@dont-email.me...
> | To be more specific, you would not be able to write a one-line,
> | multy-command "then" ....
> |
> | > as the same as a line return, simply used for formatting
> |
> | Well, that is where you problem exists. The line return terminates a
> | *line* (which can hold one or more commands), the colon only terminates
a
> | single command.
> |
> It seems that the colon terminates any line
> *except* an If/Then without problem. My
> example above includes 2 operations in one
> segment. I don't know how you can say that's
> not a line:
>
> x = 4: y = "apple": z = Instr(y, "l") + 10: x = x + z
>
> Those are all lines. [z = Instr(y, "l") + 10] is a
> compound operation. I don't know how you're
> defining a command vs a line.
>
> A colon acts as a line break. An example is in the
> WSH help, under ExecuteGlobal:
>
> 'Include multiple statements in the statement argument, using colons or
> embedded line breaks to separate them.'
>
> "Sub Proc2: Print X: End Sub"
>
> --------------
> Here's another sample that works perfectly well:
>
> Dim FSO: Set FSO = CreateObject("Scripting.FileSystemObject"):
> FSO.DeleteFile "C:\windows\desktop\test1.txt", True: Msgbox "file
deleted.",
> 64
>
> That's a whole script in a single line. Each segment
> must be a separate line. Thus, the colon is acting
> as a line return.
>
> | > It works fine in VB6.
> |
> | I strongly doubt that. Using it predecessor (VB5) a line like:
> |
>
> You're right. It turns out that a double If/Then
> doesn't work in VB6. That's disconcerting, as I've
> been using colons for years.
>
> For me the issue here is not what's officially
> correct or who's right. The point is simply that
> the design is a "gotcha". I would have expected
> my complete If/Then line to be processed in
> the same way as if I had used a line return. It
> seems to be the only case where the colon doesn't
> work properly as a line return.
>
> The multiple statement If/Then, by contrast,
> is not written in the same way. From the help:
>
> If A > 10 Then A = A + 1 : B = B + A : C = C + B
>
> That's not what I was writing. I wrote complete
> lines that were not related:
>
> If A > 10 then A = A + 1: If B < 10 then B = 0
>
> Anyway, at this point anyone who uses colons
> should understand what I'm talking about and be
> adequately warned. That's the only reason for my
> posting. I'm not concerned whether Bill Gates is
> exonerated or sentenced to hang by his thumbs. :)
>
>
>
Back to microsoft.public.scripting.vbscript | Previous | Next — Previous in thread | Next in thread | Find similar
Weird bug "Mayayana" <mayayana@invalid.nospam> - 2015-11-16 13:28 -0500
Re: Weird bug "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-11-16 19:50 +0100
Re: Weird bug "Dave \"Crash\" Dummy" <invalid@invalid.invalid> - 2015-11-16 15:28 -0500
Re: Weird bug "Mayayana" <mayayana@invalid.nospam> - 2015-11-16 16:13 -0500
Re: Weird bug "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-11-16 22:57 +0100
Re: Weird bug "Mayayana" <mayayana@invalid.nospam> - 2015-11-16 18:10 -0500
Re: Weird bug "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-11-17 01:20 +0100
Re: Weird bug "Mayayana" <mayayana@invalid.nospam> - 2015-11-16 21:11 -0500
Re: Weird bug "R.Wieser" <address@not.available> - 2015-11-17 10:44 +0100
Re: Weird bug "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-11-17 11:19 +0100
Re: Weird bug "R.Wieser" <address@not.available> - 2015-11-17 11:31 +0100
Re: Weird bug "Mayayana" <mayayana@invalid.nospam> - 2015-11-17 09:06 -0500
Re: Weird bug "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-11-17 15:24 +0100
Re: Weird bug "Mayayana" <mayayana@invalid.nospam> - 2015-11-17 10:35 -0500
Re: Weird bug "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-11-17 16:45 +0100
Re: Weird bug "R.Wieser" <address@not.available> - 2015-11-17 17:13 +0100
inline "End If" bug, was Re: Weird bug "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-11-17 17:41 +0100
Re: inline "End If" bug, was Re: Weird bug "R.Wieser" <address@not.available> - 2015-11-17 18:27 +0100
Re: inline "End If" bug, was Re: Weird bug "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-11-17 19:37 +0100
Edsger Wybe Dijkstra was: Re: inline "End If" bug, was Re: Weird bug "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-11-17 19:44 +0100
Re: inline "End If" bug, was Re: Weird bug "R.Wieser" <address@not.available> - 2015-11-17 20:47 +0100
Re: Weird bug "Mayayana" <mayayana@invalid.nospam> - 2015-11-17 12:01 -0500
Re: Weird bug "R.Wieser" <address@not.available> - 2015-11-17 18:47 +0100
Re: Weird bug "R. Roesler" <worm.composter@nospam.arcornews.de> - 2015-11-19 13:12 +0100
csiph-web