Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > microsoft.public.scripting.vbscript > #11196

Re: Weird bug

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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