Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
GOTO on Filtered data
Message
De
19/11/2004 16:30:03
Ken Dibble
Southern Tier Independence Center
Binghamton, New York, États-Unis
 
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Visual FoxPro:
VFP 7 SP1
OS:
Windows XP SP2
Database:
Visual FoxPro
Divers
Thread ID:
00962533
Message ID:
00963082
Vues:
8
Thanks Sergey,

>The GOTO < Record # > command pays no attention to SET FILETER or SET DELETE ON.

That's not documented in the Help for the GOTO topic, BTW.

>When BROWSE command runs, it issues implicit LOCATE if current record doesn't satisfy filter conditions.

And I'm still confused. It's a good thing I'm not afraid of appearing ignorant online. <g>

It seems to me that in my code, if the BROWSE issued LOCATE, then the second BROWSE would show the pointer on the first record, not the second.

If I do this with the same cursor:
GO 10

nRec = RECNO()

SET FILTER TO IntField <> 10

LOCATE

? RECNO()  && 1

GO nRec

BROWSE  && Record 10 is not visible. The pointer is on Record 9.
The Help for LOCATE says:

"If you use the LOCATE command without the FOR expression, Visual FoxPro positions the record pointer at the first logical record. This is faster than using GO TOP when a filter is in use or when DELETED is ON."

From this I conclude that a bare LOCATE should always put the pointer on the first record in the table. Granted that "logical" record isn't the same as "physical" record, but "first" means "first", right? It doesn't mean "the first record that the filter will let us show in a BROWSE window after the record we went to that can't be shown", right? Or, in the case of the above code, "the nearest record that satisfies the filter"? With no index on the cursor, it doesn't matter what nRec was; the first record is the record whose fields contain 1 and "1". It looks to me like the BROWSE isn't just issuing an implicit LOCATE. It's a lot more complicated than that. It's more like:
IF NOT EOF()
     LOCATE REST FOR [filter condition]
ENDIF

IF EOF()
     SKIP -1

     DO WHILE NOT [filter condition] AND NOT BOF()
          SKIP -1
     ENDDO
ENDIF
Have I got this right?

>>I was going to suggest that you *can't* get back to that record because under your filter, it's no longer visible. It doesn't exist in this view of the table; that's why it's "out of range". So I started messing around with some simple demo code, and I discovered this:
>>
>>
>>RELEASE ALL
>>CLEAR ALL
>>CLEAR
>>
>>LOCAL x, nRec
>>
>>CREATE CURSOR foo ( ;
>>     IntField I, ;
>>     CharField C(10) )
>>
>>FOR x = 1 TO 10
>>     INSERT INTO foo (IntField, CharField) ;
>>     VALUES (x,TRANSFORM(x))
>>ENDFOR
>>
>>GO 2
>>
>>nRec = RECNO()
>>
>>? nRec  && 2
>>
>>? CharField  && "2"
>>
>>SET FILTER TO NOT ALLTRIM(CharField) == "2"
>>
>>LOCATE
>>
>>BROWSE  && The record that contains "2" isn't visible, pointer is on record 1
>>
>>? CharField  && "1"
>>
>>GO nRec
>>
>>* With this commented out, the next line returns "2", which should be
>>* impossible, because that record isn't visible; it's excluded by the filter.
>>* If this line runs, the browse window shows the record pointer on the second
>>* record, where CharField = "3", and the next line returns "3", which is what
>>* should happen with or without the BROWSE.
>>*BROWSE
>>
>>? CharField
>>
>>
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform