Solved loop without do

[NauticalGent]

Actually, no. As it happens, I am quoting the strict statement that describes VBA syntax, and I have named the reference.

Thanks for the link Doc, please don't take me too seriously, you know how I like to "stir it" every now and again...

 

[MajP]

From the Microsoft VBA Language Specification published 04-30-2014, top of page 77 (in the PDF version thereof), and in section 5.4.2.3 For Statement I offer a couple of excerpts

Although that is fine information, it is unrelated to what I said. As I stated you just need a NEXT and no variable is required. 2016, 2012 1995 it has always been that way. Not suggesting this is good, just the way it is.

 

[The_Doc_Man]

Although that is fine information, it is unrelated to what I said. As I stated you just need a NEXT and no variable is required. 2016, 2012 1995 it has always been that way. Not suggesting this is good, just the way it is.

As long as we agree that the problem was due to an unterminated FOR loop, whether VBA is forgiving or not is less important. As to "unrelated" - I will avoid starting an argument over the word "unrelated" in this context as it is not worth it. I have demonstrated where I got that idea about FOR / NEXT syntax and therefore proved I wasn't blowing smoke.

Thanks for the link Doc, please don't take me too seriously, you know how I like to "stir it" every now and again...

As if I didn't know that, John. We're cool.

 

[MajP]

As long as we agree that the problem was due to an unterminated FOR loop, whether VBA is forgiving or not is less important. As to "unrelated" - I will avoid starting an argument over the word "unrelated" in this context as it is not worth it. I have demonstrated where I got that idea about FOR / NEXT syntax and therefore proved I wasn't blowing smoke.

Not sure why I would need to agree on something I clearly stated 4 threads before you said anything (see thread #4)

In this case it is broken because you have a FOR without a Next inside the DO Loop.

That is fine that you got an "idea" from somewhere, but I demonstrated it in code that it is not required. But I do not see how you interpreted that to support your position, it does not say that IMO.

 

[The_Doc_Man]

I don't deny you correctly identified the error. I was answering the question of why there was a specific error message and not one of the other error messages that were being suggested. You stepped in afterwards, perhaps because you didn't recognize the purpose of my post. Look at the very first line of my post #8, where I said I would explain the error message. I did exactly that. You then jumped on my case about the syntax of the FOR/NEXT loop in question and I provided hard evidence that my position was supported by formal Microsoft documentation. I even acknowledged that it might be that VBA was more forgiving than it used to be. So your problem is...?

 

[jdraw]

I know NauticalGent(John) likes to "stir things", and I can see some differences in interpretation/understanding/reality in the thread. However, like much documentation, Microsoft seems to offer some "wiggle room" .
See the NOTE in mauve just above the EXAMPLE at https://docs.microsoft.com/en-us/office/vba/language/reference/user-interface-help/fornext-statement

 

[The_Doc_Man]

Thank you for the reference, jdraw. It shows that I was right about the syntax - but so was MajP. That "exception" was not listed in the formal VBA definition I was using, the PDF language reference file.

That is one of the things that can be a little irritating (in a way) with Microsoft. Consistency can be a bugaboo with them sometimes.

 

[jdraw]

Doc,
You are very welcome. I look to you and MajP for interesting posts/responses always. Happy to find that little gem that we can all add to our "bag of tricks" regardless of the official documentation and call it a win-win.

Personally, I put the counter on the Next statements - more for clarity and debugging than conforming to rules for For.

 

[CJ_London]

Personally, I put the counter on the Next statements - more for clarity and debugging than conforming to rules for For.

totally agree

 

[Gasman]

And we wonder why new users do not dim their variables correctly

From @jdraw 's link

Dim Words, Chars, MyString

 

[MajP]

Personally, I put the counter on the Next statements - more for clarity and debugging than conforming to rules for For.

I would never not include the counter. I point this out because VBA is not precise, not because I support it. Imagine a language where you do not have to declare variables and has default properties that are not required and supposedly that simplifies things. Ohh... wait a minute I know of one.

 

[The_Doc_Man]

We certainly agree in that point, @MajP - leaving out the counter is a poor programming practice leading to confusion if ever you or someone else has to go back and revisit code after a long period. Guess that's why I actually liked programming in P/L-1G for a while. It was syntactically not a forgiving language, but if you got it to compile correctly without any data-type alerts, you knew you had cleaned up your code significantly and had no data errors.

 

[jdraw]

I agree Paul. So many of Microsoft's examples, including Northwind, have questionable value, clarity, completeness etc.

In that same general area I referenced, look at the examples for
Mid() Date()
We're all too familiar with the field names with embedded spaces in the various Northwind tables.

Dim seems complete

As Doc mentioned "That is one of the things that can be a little irritating (in a way) with Microsoft. Consistency can be a bugaboo with them sometimes."

Documentation and Northwind2 efforts will continue to improve things, but there are some inconsistencies for sure.