Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Method names suggestion
Message
 
 
À
14/03/2013 13:09:22
Mike Yearwood
Toronto, Ontario, Canada
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2008
Network:
Windows 2008 Server
Database:
MS SQL Server
Application:
Desktop
Divers
Thread ID:
01568344
Message ID:
01568488
Vues:
123
>>Hello,
>>
>>I am using a class which encapsulates most of the cursor handling in FoxPro. For example instead of GO TOP I say loCursor.GoTop() etc.
>>When I scan through a cursor very often I need to save the current position and after the scan move back to the previous record number in that cursor, which would look like this:
>>
>>LOCAL lnRecno
>>lnRecno = loCursor.Recno
>>loCursor.DoSelect()
>>SCAN
>>    *
>>ENDSCAN
>>loCursor.GoTo(lnRecno)
>>
>>I find this a little bit cumbersome, so it would be best to have two methods, one to save the original position and the other to move back to the original position. But I am at a loss how to name those methods, everything I can come up with ("SaveRecordNumber", "MoveBackToRecordNumber") do not sound anything intuitive. Anybody has a bright idea how to name those methods?
>
>A better practice is to instantiate an object that remembers the record number. When destroyed (if by release method or simply going out of scope) it resets the record number.

That is correct what you are saying, and yesterday, while creating the methods I had exactly the same idea, discarded the changes I have already done and then started to create a class to encapsulate the task for that purpose. It also would mean I don't even need to modify the original data class, which is a good thing and points to the right direction.
But then I was realizing, the original request for the change for was to simplify the repetitive code to make the recurrent task of creating a local variable and storing the record number in that variable and after the SCAN to move back to that position by remembering which variable you used before, and to make sure if you deal with multiple cursors to use different variable names for each.
So I was seeing myself instantiating this object each time before a scan, and after the scan releasing that object. I realized it did not really simplify the situation at hand and moved back to my original approach.
It would be the better design idea no doubt, but practicality wins sometimes over beauty.
Christian Isberner
Software Consultant
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform