Subject | Re: [IBO] Re: TIB_Date and DatePick enhancements |
---|---|
Author | Jason Wharton |
Post date | 2002-03-01T18:30:37Z |
No drawbacks unless you have user documentation, marketing materials, etc.
with screen shots of your application and you want things to remain
consistent. Also, some people being color-blind and people making use of
color schemes in there apps, it is preferable to use gray scale in highly
generic situations like the datepick in order to avoid conflicts. clRed is
not a good color in this situation.
Some things you added will remain without a property, like the line
separating the days from the numbers. That was a definite improvement. But,
making the days 3 characters in length is NOT a simple change so I added a
property to control its length. 2 is a nice option as well.
Make your own subclass and use it in your applications to carry your
preferred default conditions if the ones I use are not fully to your liking.
Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
with screen shots of your application and you want things to remain
consistent. Also, some people being color-blind and people making use of
color schemes in there apps, it is preferable to use gray scale in highly
generic situations like the datepick in order to avoid conflicts. clRed is
not a good color in this situation.
Some things you added will remain without a property, like the line
separating the days from the numbers. That was a definite improvement. But,
making the days 3 characters in length is NOT a simple change so I added a
property to control its length. 2 is a nice option as well.
Make your own subclass and use it in your applications to carry your
preferred default conditions if the ones I use are not fully to your liking.
Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
----- Original Message -----
From: "mmenaz" <mmenaz@...>
To: <IBObjects@yahoogroups.com>
Sent: Friday, March 01, 2002 11:23 AM
Subject: [IBO] Re: TIB_Date and DatePick enhancements
--- In IBObjects@y..., "Jason Wharton" <jwharton@i...> wrote:
>
> I added these changes but in the form of properties having default values=
so
> that the control will be exactly the same as it is now. It is not accepta=
ble
> to me to implement changes which will affect an application's appearance =
and
> existing behavior (unless fixing a bug) in significant ways.
>
First of all, I want to say that YOU decide what to do with IBO, sure not m=
e :)
But having said this, I want to outline, in this case of my IB_Date enhance=
ment, these situations:
a) I've added the "auto today fill" behaviour.
Ok, it can be a problem of compatibility, so a property to set it is ok
b) Added doBoldSaturday, doBoldSunday to display in boldface Sundays and/or=
Saturdays.
Already properties, I think is really better having them disabled
c)added a vertical line separating number of the week from the days of the =
calendar.
d) Day of the week now is 3 letters long.
e) Cells a bit wider to better accommodate bold fonts, number of the week a=
nd 3 letter name of the day.
f) Changed day and lines color to clNavy, today border to clRed (better con=
trast).
c)-f) on my opinion are improvements with no drawbacks. The c) is really a =
must, since without it's hard distinguish the week number from the first
day=
column. d) is needed too, since, for instance, in Italy we have two
consecu=
tive day name with the same starting letter (Martedì, Mercoledì...). 3
lette=
rs can only be a benefit. e) the original control was so little that you
can=
hardly read it... if it's a visual help, it must be visible and good for
mo=
use pointing and day reading. f) I like those color, but it could be a
matte=
r of tastes. If you provide color properties for them it's sure good.
Just some thoughts to avoid property proliferation and improve standard IB_=
Date usability...
Regards
Marco Menardi