David,

Firstly, I promised you a code example.
Please don't complain about the naming, which we keep compliant to the field lengths in the dbf (and we don't use dbc).

The Spinner's class Valid as an example (all controls have slightly different code here) :

PRIVATE THISFRMV
PRIVATE THSV
PRIVATE VDRESULT                       && Catches the result of the Valid function.

THISFRMV = THISFORM
THSV     = This

VDRESULT = SYMTICVD()                  && Valid.

*** 24-06-98,JB;
*** When the Valid is negative, the complete control will appear as selected.
*** Hence, for a spinner this is useful.
*** This means that the ClipBoard buttons in the MainToolbar have to be
*** updated (Cut and Copy have to become available).
*** This will be done by means of the "UpdateClipButtons" method from the
*** MainToolbar object. It uses 2 parameters :
*** (1) SelStart (cursor position) and (2) Sellength (selected chars from 
*** off SelStart). When both are 0, this implies a reset of the ClipBoard buttons.
*** Cut and Copy are not available then, and Paste is dependent on _CLIPTEXT.

IF .NOT. VDRESULT
  TBRHOOFD.UpdateClipButtons(0,len(THSV.Text))
ENDIF

RETURN VDRESULT

RETURN

The Valid UDF (SYMTICVD) :
It's a snippet from general 1,600 line Valid code, most of it comment.

IF KEY = 'Backspace' .OR. KEY = 'Larrw' .OR. KEY = 'Home' .OR. KEY = 'End' .OR. KEY = 'Rarrw'
  RETURN .F.
ENDIF

IF KEYPRSSD .AND. (LASTKEY() = 5 .OR. LASTKEY() = 15)  && Uarrw or SH-TAB. WR, 19-02-2002.

* IF KEYPRSSD .AND.;
*   LASTKEY() = 5   .OR.;              && Uarrw.
*   LASTKEY() = 15                     && SH-TAB.
**  LASTKEY() = 1                      && Home.
**  LASTKEY() = 19                     && Larrw.
**  LASTKEY() = 127                    && Backspace.

  *** Refer to SYMTICGF (GotFocus) under 10-05-98,PS  for the commenting-out of the last 3.

  *** Note !
  *** When the first control is active, and we use Uarrw to move to the last control,
  *** then this check just doesn't work. IOW, in this case the first control won't
  *** be validated.
  *** ==TO BE SOLVED==.
   
  EXITCTRL = 'Up'                      && Tell user function that control was left upwards.
  
ELSE                                   && Other keys will leave downways.
  EXITCTRL = 'Down'                    && Tell user function that control was left downwards.

ENDIF

*** Somewhere down the line the function returns .T. or .F. for the real validation.

David, I assume that you will agree that the UDF's code could be moved to some custom method on the form (or even another, in fact, unrelated) object;
I don't do this, because a. it really hasn't anything to do with the form (just suppose I had two main form classes, which I btw don't have) and b. the explicit calling of a method (from a VCX) is significantly slower than the calling of a function in a PROC (SYMTIC* functions are in a PROC).


Further, some small notes on the "losing of data" at encountering the record was changed before OK :

When the form comes back with the message "didn't update because someone else just did", there are a few options.

1.
The user is presented the original data as from before the OK.
But what to do with that ? Press OK now will again override the data from the other user who just applied the update.

2.
The user is presented the current data.
Is of no use at all, because the data the user just typed is lost. He has to type again.

3.
The user is presented the original data, and besides that, the changed data by the other user (the current data).
What to do with that ? It will come to re-typing again.

Note that 1, 2 and 3 can be avoided when first is sorted out which fields changed, and possibly there isn't a common denominator, so the user just could apply his OK. So, assumed the app works like this, 1, 2 and 3 are not about that.

In addition, there is the RI thing. Just suppose that somewhere down the line is implied that a relator has to be deleted. Or better, that the FK's from the form changed, imply a delete of the old relator record, and the addition of a new record. How to deal with that ? Hence, if this were the case, it wouldn't even be legitmate at all that the user is in the form implying the change to come, because it would also imply that he couldn't reach the form in the first place (after the other user changing the relators' records).
Remember, for the general discussion we can't talk about the 1 table only bound to the form, but many many more involved, but indirectly.
When 1 fails to update, you must provide the user with some "why". This "why" can't be derived from logic, since nothing's on the form about some deep down rejection. This is situation nr. 2 above. Then what ?

Many situations exist that the form couldn't be re-entered, but the user is still in there anyway. IOW, pressing OK once more (and update status has been reset now), will just imply the illogical situation. IOW, there must be some additional provision similar to at entering the form, but now from within the form. It's redundant.

IMO there is one good solution only : check upon entering the form whether the OK button will work, and preserve that situation. We call this "locking".

I don't think this is a matter of another opinion, but a matter of how decent we want to make apps, how few work we want on creating and maintaining them, and how friendly they appear to the user.
But okay, opinions can differ on that obviously.
And remember, I am almost on my own here. So maybe I'm just all wrong.


About the web-apps validations : Yeah, sure, you are right. But I was already saying it ("that's my problem"). So one again : the way I like to validate at the control level, sure doesn't suit the webapp. But hey, untill now it looks like a sheer impossible job to find a webapp that I am content with. Once I have to start filling out forms overthere, beware for my mood. I hate it. Just direct me to one proper webapp with respect to this, please. I could learn from it.
Until I can't, I will have the valids at the control level. By means of overheaded communication, sneaky java, dynamic SP's from a connected backend, whatever. But I will succeed on it. I just hate the form communication far too much. And you know, this is back to the early days of screen computing. Back then it was called "blockmode" I think. It's the most user unfriendly that was invented. Yesterday I mean.


About the binding of biz-objects : This is an area I find, honestly, difficult to judge properly. It is my opinion that there is just too much involved, and from one week to the other new possibilies emerge. Just one drastic example : we are able to make a COM of each of our biz functions. This looks like rather overdone, because there are so many (thousands). OTOH, it would be the most farout component-based system, and because of that, I tend to go that way. Well, as you can imagine, this would bind them more to "objects" opposed to right now. By nature.
Once we would have this scenario, why go back to the normal situation. Okay, but what are the cons ?
ADO, XML, COM, DLL, Remote Backend, SP's or UDFs for that, RV's, SPT, DCOM, Webservises, Webapp ... hell, all can be combined in almost any order. Oh, forgot .NET.

Peter