There is some really ugly code in the form builder as both Tom and Jeff point out. I'm hoping to find some time to do some serious clean-up. I personally dislike the style in which it is written but I see no reason to do a large-scale rewrite for that reason alone. I'm only interested in cleaning up functionality, complete uncompleted stuff (as I've partially done with the date and currency types for 4.6), etc.
My goal will be to make the data types straightforward and easy to use and better integrated with ad_form.
I agree with Jeff's statements regarding the fact that inline errors are extremely useful, the fact that ad_page_contract and the form builder don't really fulfill the same need, etc etc. Also writing new presentation templates for the form builder is actually quite easy once you understand how the "standard" template works. I've written several and it's very convenient to be able to write a small set of templates that can be shared by all form pages on a client sites.
Strangely enough, some clients seem to really care about the look of forms on their site and the templated form builder supports this surprisingly well. It is rather opaque, I admit (easy for me to admit since I didn't write it!)
As far as usability, I wrote ad_form because I decided hiding the original API would be a lot easier than rewriting all of the templating form builder code.
Now, as I mentioned elsewhere I think it won't be that hard to allow use of ad_page_contract-style filters with ad_form, for trimming and that kind of thing.
Dave ... as far as your problem goes I think you may've uncovered a boneheaded implementation strategy on my part, i.e. the validation block shouldn't be executed until all the form elements are created. I thought that was true, frankly ... I'll look later today.
In the interim, remember that the "on_submit" block is executed before the "new_data" or "edit_data" blocks and after all form elements are created. You can use the form builder's set_error procedure to put the error into the form after calling the text-html proc, which does the required html security check for you as well as do the right conversion.
Oh, damn, that proc returns an error string if there's a problem ... that's not much help. Can't really expect your code to check for the error string then set the error! OK, I've got a few things to look into today, thanks, dude!