Subject [IBO] Re: IB_Date (testing, QA, etc.)
Author mmenaz
Well, I since I've submitted many <g> improvements, I don't know exactly what you are referring to. In general:
a) - Value function: do you want to "roll back" it or not?
b) - auto fill if empty
c) - auto fill if empty or content selected
d) - autofill with 2 digit years even for a 4 year mask (to avoid typing century).

a) is easy to sub-class
b-d) are all in the TIB_CustomDate.KeyPress dynamic method, so it's easy to override too.

So *I'm* ok, but did you received complaints for b-c (d is not released)? Since I've difficould in testing D3-D4 (maybe D4 is enought, since you will drop D3 support), is there something wrong with them?
d) what about implementing IFDEF so it's included only for the version it works?
I mean, if people find b-c very useful, and d) will be even more, why drop them for all instead of dropping d) for D3-D4 users only? Could it be a good idea?
If you think that people does not like them, it's ok to drop them, but if you think that people are very happy with them I think we could keep them (or build a TEST version for them ;)
(sorry for being a little repetitive, but my English is not good enought to make it clear at the first try ;))
Best regards (and, above all, my best wishes for your daughter's health).
Marco Menardi

--- In IBObjects@y..., "Jason Wharton" <jwharton@i...> wrote:
> If the changes people submit for inclusion in IBO will not work on all
> versions of Delphi I support I try to IFDEF them out. If I cannot figure out
> a way to do that, they get rejected. In your case, you have two options.
> Rewrite your changes so they will work with Delphi 3 and 4 or suggest
> changes enabling you to put them in your own sub-class and then your code
> can be plugged in at that level and IBO can continue to work the same for
> everyone else.
> Jason Wharton
> CPS - Mesa AZ
> ----- Original Message -----
> From: "mmenaz" <mmenaz@l...>
> To: <IBObjects@y...>
> Sent: Monday, April 29, 2002 2:33 PM
> Subject: [IBO] Re: IB_Date (testing, QA, etc.)
> > Replied each sentence below :)
> >
> > --- In IBObjects@y..., "Jason Wharton" <jwharton@i...> wrote:
> > > I plan to avoid the "release in order to test" mentality. The only time
> I
> > > will release in order to test is when I specifically indicate a release
> as a
> > > test release. I assume that the majority of my customers don't want to
> feel
> > > like their efforts are doubled as my QA efforts.
> >
> > Yes, you are definetly right. And consider that if you flag a release as a
> "test" one, usually you have to introduce significant (for the programmer)
> advantages to make them test it...
> > When I submit some improvements to you it's something I've tested in the
> situation I'm using it, so I count on your test too. But what I meant is
> that we two can test only a (small) finite number of situations, so we will
> never be sure about the testing.
> > Beyond this specific situation (TIB_Date), do you think would be good
> having a "tester" release and a "production worthy" one (like Linux)? A
> developer release tested by selected guys that want to help you, but also
> open for everyone "brave". As a IBO contributor, I would be much sure about
> modification I make too.
> >
> > >
> > > IBO is something I ask money for and as a result I feel it is my
> > > responsibility to make sure my releases are production worthy upon
> release.
> >
> > Yes, Borland is asking money for VCL too but D6 ActionManager component is
> not that great example of QA <g>. Nothing I've seen compares with IBO in
> quality and details.
> >
> > > I do a significant amount of testing and take great caution to make sure
> > > this remains the case.
> >
> > Thank you, I benefit from it too.
> >
> > >
> > > Your changes were all supposed to be "rolled back" because of the other
> > > problem that other code introduced.
> >
> > I really use them, so I will have to inherit from your code a specialized
> component of apply the changes every release you submit (I will see the best
> solution). That is not a big issue, but since I would like to keep being in
> syncro with IBO standard and have other people benefit from my work (I've
> spent a lot of time upon it), can we collaborate in fixing it for your
> customers too? Or do you think that it does nothing that worths the trouble
> or that can not be fixed for all the platforms you support?
> >
> > Thanks
> > Marco Menardi