About "the most common date format": I think that very often used date
separator is also a dot '.', not only '/'.
I still use older version of IBO (Hc), but I wonder if the very quickly
evolving changes in this area will impact my existing code (as my latest
upgrade to Hc and some undesired changes in displaying datetime fields in
tib_grid; this was commented in some weeks ago here in this forum).

I will always agree with your effort and support it because I believe this
can make manipulating with dates and times very easy, but keep in mind, that
these changes CANNOT affect existing code (or maybe cannot affect the code
significantly). As the IBO is used all over the world, the changes in
datetime routines are very sensitive. Better is to be little bit
conservative here.

Again, I will support your effort, but, please, consider this.
Thank you,
Ales

> -----Original Message-----
> From: Marco Menardi [mailto:mmenaz@...]
> Sent: Saturday, September 21, 2002 7:39 PM
> To: IBObjects@yahoogroups.com
> Subject: [IBO] About a change in IBC_DATE.IMP
>
>
> I've tested the modification by Fabio Bot with the auto
> completion of the year in IB_Date component and it works good.
> Just some general consideration:
> a) since this will have no sense if AutoFill is true, and
> since they have the same goal (ease user input reducing
> keystrokes), there should be a single property to regulate both, like:
> AutoCompletion (acNone, acFill, acYearComplete)
> b) would be good if it will work with a two year definition
> too, so I could enter 05/04 and have 05/04/02.
> c) you can't write such input facility with every possible
> combination of date format in mind, but I think that the most
> common are mm/dd/yy, dd/mm/yy and yy/mm/dd (or with yyyy). It
> would be great if the control could fill the most part of
> information it can, like if I enter "05" consider this always
> a day specification, and so add month and year, whatever
> format I'm using (so acYearComplete will be acComplete).
> d) additional UnboundDisplayFormat and UnboundEditMask
> property (maybe a shorter name, but with the same prefix) to
> exploit the full possibilities of the control in unbound mode too.
>
> The a) idea will broke backward compatibility a little, but
> it will make the control more usable and will save future headaches.
> Fabio, IBO community and Jason input is required ;)
> Regards
> Marco Menardi