At 10:24 PM -0400 7/30/2005, Dennis Brown wrote:
I never had any trouble remembering that something in a loop
variable is a copy, because that is what I would expect. However,
it appears that what we have is just a label, not really a variable
--that is until we exit the loop, then we have a v
Jon-
Monday, August 1, 2005, 4:43:41 AM, you wrote:
> Whew! That's more like it!
Yes, indeed. I'm glad I was wrong on this one.
--
-Mark Wieder
[EMAIL PROTECTED]
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url
Whew! That's more like it!
Ken Ray wrote:
On 7/31/05 8:13 PM, "Jon" <[EMAIL PROTECTED]> wrote:
Horrifying. I assume this is BZd?!?
No, because it's not true (see my response to Mark).
Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: [EMAIL PROTECTED
Ken-
Sunday, July 31, 2005, 9:09:22 PM, you wrote:
> Sorry, Mark, but that's simply not true. You can check this this way:
Well, OK, now that I go back and test it again it's all working fine.
But look, this has happened to me before. Several times. And the only
thing that would fix up that spur
On 7/31/05 8:13 PM, "Jon" <[EMAIL PROTECTED]> wrote:
> Horrifying. I assume this is BZd?!?
No, because it's not true (see my response to Mark).
Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: [EMAIL PROTECTED]
___
use-
On 7/31/05 7:08 PM, "Mark Wieder" <[EMAIL PROTECTED]> wrote:
> A semi-related point that seems to bother nobody but me is that you
> don't have to declare loop variables (i.e., Variable Checking [aka
> explicitVars] doesn't catch them), but if you don't explicitly declare
> them as local then the
WHAT
I would have thought that they would be local by default.
Who would ever guess that they would be global by default.
This is unbelievable --and dangerous!
Come on now, April 1st was four months ago.
Dennis
On Jul 31, 2005, at 8:08 PM, Mark Wieder wrote:
A semi-related point that see
Horrifying. I assume this is BZd?!?
Mark Wieder wrote:
Jon-
Sunday, July 31, 2005, 12:15:53 PM, you wrote:
J> Mark:
J> The point I was TRYING to make was that FOR loop variables 1) had
J> to be declared locally; and 2) could not be modified inside a loop. I
J> was trying to make a genera
Jon-
Sunday, July 31, 2005, 12:15:53 PM, you wrote:
J> Mark:
J> The point I was TRYING to make was that FOR loop variables 1) had
J> to be declared locally; and 2) could not be modified inside a loop. I
J> was trying to make a general case for this kind of a definition of an
J> "error".
Ah.
Dennis-
Sunday, July 31, 2005, 1:45:53 PM, you wrote:
Thanks. BZ# 3036 voted and commented on.
--
-Mark Wieder
[EMAIL PROTECTED]
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and mana
Ok folks,
I BZ'd this issue for the Rev team to take note of. If you want to
second this, you can send a vote it's way.
Thanks to all for the discussion and helping me understand the problem.
Dennis
--
http://support.runrev.com/bugdatabase/show_bug.cgi?id=3036
Summary: R
Mark Wieder wrote:
I wasn't aware that Delphi even *had* a "for each" element construct,
That's part of Pascal, no?
I may just be getting old
--
Richard Gaskin
Managing Editor, revJournal
___
Rev tips, tutorials and more: http://www.
Mark:
The point I was TRYING to make was that FOR loop variables 1) had
to be declared locally; and 2) could not be modified inside a loop. I
was trying to make a general case for this kind of a definition of an
"error".
:)
Jon
Mark Wieder wrote:
Jon-
Sunday, July 31, 2005, 5:59:01
In Python, too, you can change the loop variable; but every time
execution goes back to the top of the loop, the variable takes on the
next value it _would have_ taken, no matter what you've done to it in
the meantime. (If I remember right.) Kind of a handy combination --
as long as you rem
Jon-
Sunday, July 31, 2005, 5:59:01 AM, you wrote:
J> It has been considered a bug, and flagged for the programmer, in Delphi
J> for years. I don't see how it can be considered anything else. Now as
J> to whether it is a bug that is reported in Rev with an error message,
J> that is a different
It has been considered a bug, and flagged for the programmer, in Delphi
for years. I don't see how it can be considered anything else. Now as
to whether it is a bug that is reported in Rev with an error message,
that is a different story.
:)
Jon
Mark Wieder wrote:
Dennis-
Saturday, Ju
Dennis-
Saturday, July 30, 2005, 7:24:58 PM, you wrote:
DB> I would really like to get a real error message since it does not do
DB> what you expect from reading the code. How many newbies do we have
DB> to trip up before we erect a stop sign at that intersection?
DB> Should I BZ it?
I'm not s
Mark,
I never had any trouble remembering that something in a loop variable
is a copy, because that is what I would expect. However, it appears
that what we have is just a label, not really a variable --that is
until we exit the loop, then we have a variable with the last
contents in it.
Dennis-
Saturday, July 30, 2005, 12:13:06 PM, you wrote:
DB> >> Important! You cannot change the labelVariable in a statement
DB> inside the loop. Doing so will cause a script error..."
DB> Well I never got that script error message!
Well, it's not exactly an error "message"... it *will* cau
On Jul 30, 2005, at 12:59 PM, Jan Schenkel wrote:
Hi Dennis,
I believe this was largely due to modifying the
control variable within the repeat loop. I
made some other changes, and you'll find the result
below:
I guess I don't understand the repeat for each control structure they
way I th
On 7/30/05, Dennis Brown <[EMAIL PROTECTED]> wrote:
> I have the following script (much simplified from original).
> In the form shown, it generates results and saves them into the
> following variable names:
> openSAW
> openSAWW
> openSAWWW
> openSA
> openSAW
> openSW
>
> This is not what
--- Dennis Brown <[EMAIL PROTECTED]> wrote:
> I have the following script (much simplified from
> original).
> In the form shown, it generates results and saves
> them into the
> following variable names:
> openSAW
> openSAWW
> openSAWWW
> openSA
> openSAW
> openSW
>
> This is not what I
I have the following script (much simplified from original).
In the form shown, it generates results and saves them into the
following variable names:
openSAW
openSAWW
openSAWWW
openSA
openSAW
openSW
This is not what I intended!
However if I make a small change to the script as shown i
23 matches
Mail list logo