Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Class keeps changing DataSession
Message
De
03/08/2002 12:58:45
Charlie Schreiner
Myers and Stauffer Consulting
Topeka, Kansas, États-Unis
 
 
À
02/08/2002 11:21:53
Information générale
Forum:
Visual FoxPro
Catégorie:
Classes - VCX
Divers
Thread ID:
00684772
Message ID:
00685897
Vues:
31
Hi Bill,
We use the same sort of structure as you are describing--but each cursor object has its own validation object.
As I see it, you have two options.
1. Create validation objects in the same DS as the cursors.
2. Pass the data you wish to validate to the Validation object.
Taking 1. first.
We have a DE class that contains all the cursor objects that we are concerned with for a specific form or task. Each cursor object has its own Validation and Rules object. We have a couple of subclasses of validation objects--some store messages in an array, some in with the data. The rules deal with EnableDelete, EnableAdd and such. If you can't delete for example, the WhyICantDelete property shows the reason.
The validation object lives in the same DS as the cursor, a view in this case, so it has access to the fields. Here's part of what happens--this is from memory, so I might leave quite a bit out.
In the Form's Validate()
Message = ''
Severity = 0
IF ThisForm.oData.Validate(@Message, @Severity)
   * Everything checked out.
   Action = "Save"
ELSE
   Action = ThisForm.GetUserInput(m.Message, m.Severity)
ENDIF
RETURN ThisForm.DataAction(m.Action)
* Return .T. to indicate OK to go on. .F. means stay here.

In the DE's Validate(Message, Severity)
FOR EACH oCursor IN This.aCursors
   oCursor.Validate(@Message, @Severity)
ENDFOR

In each cursor class's Validate(Message, Severity)
ChangedRecNo = GETNEXTMODIFIED(0,.Alias)
DO WHILE NOT m.ChangedRecNo = 0 
IF This.oValidate(@Message, @Severity)

* BaseClass does this from the list of fieldnames. This enables the form
* to call these same methods as needed.
IF PEMSTATUS(This, "v" + m.FieldName,5)
   * Now validate this field.
   RetVal = EVALUATE( "This.v" + m.FieldName + "()" )
   * Valid must set the Message and Severity properties.
   IF NOT m.RetVal
      Message = m.Message + This.Message + CRLF
      Severity = MAX(m.Severity, This.Severity)
   ENDIF
ENDIF	
RETURN m.RetVal

* In the SubClass I write the methods needed to validate. 
PROCEDURE vFirstName()
LOCAL RetVal
IF EMPTY(Customer.FirstName)
   This.Message = "Fill this in."
ELSE
   RetVal = .T.
ENDIF
RETURN m.RetVal

or

PROCEDURE vSSN
LOCAL RetVal, Name
Name = ''
IF This.oParent.Check4Dupes(Customer.SSN, @Name)
   * oParent is the cursor object that created this Validation object.
   * Can't use addobject, so we use this property to refer to our creator.
   RetVal = .T.
ELSE
   This.Message = "SSN-" + Customer.SSN + " has already need used by " + m.Name + "."
   This.Severity = 4   && Warning.
ENDIF

Taking the 2. approach. 
I haven't done this, but here you could do methods like this.
SCATTER NAME oRecord MEMO
IF This.Validate(oRecord, @Message, @Severity)
* Here the Validation object is passed the data to validate. 
* or 
IF This.Validate(oCursor, oRecord, @Message, @Severity)
* Your validation object now can check for consistency of the data, and if
* it needs access to the DS, it can call a method back in the cursor object. 
IF oCursor.Look4Dupes(m.ID, Message)
>I'd be interested in your opinion on how to do this in an OOP sense.
>
>I'm creating a Record/Field Validation Class. One sub-class for each table. Each field and trigger will have a method of it's own. The idea is that the parent-class has code that is used for EVERY table and then an individual sub-class for each table.
>
>The problem is having a single object doing validation for several different DataSessions. I figured that I would Create the object in DS 1, and pass the correct DS to the object. It worked fine for a while, but then stopped. When the code that is in the parent-class (the parent-class code would set the DS) called the individual method in the sub-class (in the same object), the DS went back to 1.
>
>It's starting to look like I'll have to create a different object for each table in each DataSession. I'll also have to figure out how to have the DataSession close the objects that are created in it, so the DS can be released. I was hoping to create each object once, then use it every time I opened the table it was created for.
>
>Any opinion is welcome.
Charlie
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform