LOCATE FOR condition1 WHILE condition2 VS. LOCATE FOR condition1 AND condition2

The difference is not so small...

LOCATE FOR condition1 AND condition2
locates the record which meets the given condition from the beginning of file to its end (or to the first match)

LOCATE FOR condition1 WHILE condition2
locates the record which meets the given condition from the current record and the searching is finished when the WHILE condition evaluates to .F.

LOCATE FOR condition WHILE expression

condition to be evaluated at every record
expression is a memory variable or something not related to the record

LOCATE FOR recordcondition WHILE lEscapeNotPressed

Are you suggesting that it's something of an asynchronous condition watch? Otherwise shouldn't "FOR recordcondition AND IEscapeNotPressed" would work just as well?

That could work as well but I did not test it.

I have not written the LOCATE function but I guess it has a break that if a certain condition is not true then it breaks instead of evaluating the condition at the record. Could be done so for performance sake.

Memory variable? Asynchronous condition testing? It does not sound believable :-)

To issue LOCATE command with its possible interruption by some VFP API function sounds as a curiosity having no real implementation. But who knows.

The question is why to slow down the LOCATE command by some additional memory variable testing which is constant during the record searching.


LOCATE FOR condition1 WHILE condition2  is possible to use on table where the index order is set:

USE table
SET ORDER TO TAG sometag  &&  indexed on somecolumn
IF SEEK("SomeValue")
  LOCATE FOR condition  WHILE somecolumn = "SomeValue"   &&  Locate record in range given by WHILE condition
  IF FOUND()
    *-- record was found
  ENDIF
ELSE
  *-- No match in SEEK
ENDIF

Above approach can be faster than Rushmore optimization sometimes.

I used a WHILE in a SCAN once and it did not work like a FOR.

It was a long recursive routing on a big table and I used it for a memory variable which gets calculated in the loop and it worked like that.

Yes, this is reasonable usage of the WHILE clause in a SCAN loop. The recursion could cause some unwanted behavior due to the record pointer changes but it is nothing unsolvable.

I'm dying to understand this. I still can't see a situation where

LOCATE FOR condition1 AND condition2
would result in longer execution than
LOCATE FOR condition1 WHILE condition2

does it work like this:

WHILE condition2
{
LOCATE FOR condition1
}

Thanks.