Peter,
Code comments removed just for brevity of reply>The Spinner's class Valid as an example (all controls have slightly different code here) :
>
>PRIVATE THISFRMV
>PRIVATE THSV
>PRIVATE VDRESULT
>
>THISFRMV = THISFORM
>THSV = This
>
>VDRESULT = SYMTICVD()
>
>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)
>
>
> EXITCTRL = 'Up'
>
>ELSE
> EXITCTRL = 'Down'
>
>ENDIF
>
>
A couple of comments about the above code
1) It uses PRIVATE to communicate with the called function. IMHO this is bad. In an event driven environment you have the possibility of trashing these variables with a complex event sequence that is hard to replicate or test.
Everything that goes into a UDF needs to go through it's parameter list.
2) You that you want to remove replicated code, but in fact you have large blocks of code that are replicated in every one of the methods that is calling your UDFs.
>PRIVATE THISFRMV
>PRIVATE THSV
>
>THISFRMV = THISFORM
>THSV = This
This is a large amount replicated code.
>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;
The only place you are using this code is from a form, so yes I think they ought to be methods of the form class hierarchy. Or they can be other classes that the form can use.
>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)
They could have a common ancestor class. They could both decorate with other classes to do the work.
>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).
The difference in calls to methods compared to calling a UDF is only measureable in tight loops where hundreds to thousands of calls are being made. It's only significant at the hundreds of thousands of calls or more. This sort of calling level is just not happening in the GUI.
>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.
Simultaneous data update collisions really is a whole other topic of discussion, it was not clear that that is the sort of thing you are trying to make your error handler deal with.
>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 ?
RI, again, a whole separate topic, and again not one that I'd really design an error handler to cope with it.
>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 ?
If you want to make UDF calls rather than method calls because of speed concerns, you certainly don't want to be making COM method calls. A COM call is orders of magnitude slower. This is insignificant for a few calls, it is very significant for lots of calls.
>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.
We keep getting more and more options to use everyday.
