Hi Mike,

zip went to the mail account shown on UT.

>>Coming back to "personal style": While I use different patterns of dynamic code from class/method factory approaches over the snippet factory up to a table based rule engine generating whole elaborate functions I will keep trying to formulate fast checks via pre-processor - as this IMHO speeds up reading code (as neccessary for maintainance) und *for me* eliminates some "stupid blunders"/typo's. And I'ld always tryx to refrain from afields()-based approaches, as this ***can*** put a real damper on the speed of the check which makes that approach unusable as basic abstraction.
>
>I tend to play down the "style" thing. I've had to adapt to too many "styles". Where it's not a matter of style, ie AFIELDS versus FIELD - there are definite behavioral and performance issues - I wish we could try to agree on balancing performance, maintainability and constructibility. That's what I image a group of engineers would do.

I guess we would see eye to eye on this one:

1 - afield() intolerable because of performance issues
2 - field() via #define a viable possibility, fast but a bit brittle
3 - fsize() via #define even faster, but dangerous because of set compatible, therefore not viable
4 - udf() checking/handling set compatible before fsize() - safe but slower than udf() using field()
5 - udf() using field() fastest udf, no maintainance worries

I can live easily with options 2 and 5 and will argue for 2 probably only if the app/FWK uses more than 10**4 calls to test field presence between (supposedly) fast screen interactions.

regards

thomas