> You will never succeed in testing something 100% without releasing for

other people usage.

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.

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.
I do a significant amount of testing and take great caution to make sure
this remains the case.

Your changes were all supposed to be "rolled back" because of the other
problem that other code introduced. I just missed removing this part too. It
should have been removed until I was able to test all your changes. I either
should have removed it or tested it... A problem of this nature is not
beyond my ability to detect ahead of time. DFM issues are often a source of
trouble and a place I am keen to test.

Just because IBO's sources are made readily available doesn't mean I feel
like I can lower my testing standards. I feel like they actually need to be
improved, not relaxed.

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "mmenaz" <mmenaz@...>
To: <IBObjects@yahoogroups.com>
Sent: Monday, April 29, 2002 10:05 AM
Subject: Re: [IBO] IB_Date


> --- In IBObjects@y..., "Jason Wharton" <jwharton@i...> wrote:
> > Please just strip the Value properties out of the DFM before opening it
in
> > the designer.
> > In the code, put the Stored directive to false if you want to avoid this
in
> > the future.
>
> The only problem is that I've put it in the published part, while it's
intended to be only a runtime property.
>
> > I'm probably just going to remove this property since it is entirely
> > unnecessary.
>
> Who is using the control in ubound mode find it very useful indeed, and
IB_Date is one of the most useful controls in unbound (for range data
selection).
> Of course, you can do it in code, as I did before introducing Date
property, but there are plenty of things I could do in code, but I find
wonderful IBO does for me :) IBO visual control superiority over VCL is, I
think, more "appealing" than simple connection.
>
> > I merged it in for a user without testing this sufficiently and am
paying
> > the price.
> > It's great to get improvements. I'll try and be more careful in the
future.
> > That's my part of the deal.
>
> You will never succed in testing something 100% without releasing for
other people usage. With my setup the improved component was 100% ok, and I
fixed the problem 10 minutes later having read the Geoff message. You
receive bug submissions, I think, every day, but only when the code is
released and people test it in their programs. I think that IBO community
can't be hurted if you make one mistake, since we can easely revert back to
the previous version :)
> So why drop the Value function? Let's make it work (just removing one line
of code...).
> Hope you will agree with me, and I don't defend that function because was
introduced by me, but was introduced by me bacause me, one other guy and
yesterday one more need it, and I think (like you did) it's convenient :)
> Crossing my fingers...
> Thanks
> Marco Menardi