>
>So if Open() fails, it won't trigger the error handler?
>
>Hmmm
If any object has anything in its Error Method, or there is an error method in any object in the call stack, that Error Method runs--NOT the ON ERROR trap. So once you start using any Error Methods, you don't know if the ON ERROR will hit or not, depending on your object's relation in the call stack, etc.
The UseTable class, DOES have code in it's Error Method. This Error Method code stores the error, but leaves it up to you to decide what to do with it. Open() returns false when the USE fails. The Error Method soaks up and stores the error, if one occurs. It's the same idea as USE EXCL and see if it works. The difference is that this behavior is codified in the class--I don't have to think about ON ERROR and restoration and is there an Error Method in the call stack. I only do oUse.Open(). If its reports .T., I'm done.
Of course there are additional benefits.
1. What about USE (SomePath + FileName)? Couldn't the class have a default way of determining the path?
2. What if the app is just starting up and the table doesn't exist? Couldn't there be a CreateTable Method to create it?
3. How about saving the pointer? I have a bookmark property. When it is assigned, the current record is moved to correspond. When it is accessed it returns the current pointer.
4. What about checking to see if the FPT, CDX, and DBF all exist? Depending on the situation, I may want to avoid an error and better inform the user as to the problem.
5. If the table is already open, when I destroy, I leave it open, if not I close it. If the table was in use SHARED, and I use it EXCLUSIVE, I restore it to SHARED. You get the picture.