I'm testing 4.2Hc Test and seems to work very good. I'm also very satisfied about some improvements that are included: thanks Jason, I really do need them :).

Just curios to know IB_UpdateBar OnDataChange, that I've removed but Jason has kept.
Is there any situation where the IB_UpdateBar should react to such an event? I did not figured out any, but I've not done exhaustive tests or deep thinking. And like as TIB_Date demonstrates, you can't think enough;). Any thoughts?

Also, I sent to Jason a improvements in LockSQL. I think that many that want to use explicit LockSQL have a "dummy" field used for that purpose, like LOCK_FLG CHAR(1), that is set "Y/N" and managed by update triggers.
So I've found very annoying having to specify a whole query syntax, while it would be very good the one generated automatically by IBO except that it should work only with the desired field.
So if you specify a LockSQL without the "UPDATE" keyword, I assume it's in the form of LOCK_FIELD=LOCK_VALUE, ie LOCK_FLG='Y', and let IBO build the other parts of the query, if possible. Do you think that is convenient, are there any drawbacks? Any other interested in this feature?

Finally, I've seen more and more TPickDate properties "surfaced" by TIB_Date. At the beginning it was a nice thing, but now seems to make the control a little messy. I mean, I want all those to control PickDate look, but would not be better "publish" FPickDate as a whole? (or a TPickDate descendant with only relevant properties?) That way you could reduce IB_Date properties number, have them better organized (you immediately know that that property is about PickDate), and have more control upon PickDate too. Maybe compatibility could suffer, but should be nothing serious, since I think that now few people use IB_Date with settings different that default. So, I think, or the change is done now, or it could not be possible to do in the future, when people will start using them... what's your opinion?

Thanks to you all
Marco Menardi