by Well, I used to just love Crescent. When they were acquired by Progress,
I didn't think it hurt anything. I still doubt that has to do with what
I'm finding now. I found it no big deal when the PowerPakPro 1.0 docs
all had a wrong number for Tech Support - at least the techs at that
other part of Progress Corp were able to get me the right number.
But even then, a year ago, no one could tell me how to determine
which property of each control from QuickPak/PowerPak was its "default"
property. I had a backlog of legacy code that needed updating,
and it used "default" properties all over the place. So, much more
work for me, I had to test & figure them out for myself. Something
that _should_have_been_ a simple entry in the manual and helpfile.
But I let that go, and happened to not use their VBXs for a few months.
I still believed that I had a suite of good quality tools to rely on.
And now...
All I wanted to do was use the CSTEXT.VBX from QuickPak/PowerPak
(I've paid for both packages, including upgrading to the new OCXs).
My client brought me an application with Masked Edit (MSMASKED.VBX)
controls all over it, and they just want some slightly different
behaviors:
For the display-only fields, they want the appearance
of a label, and for the user to be unable to change
the value. Setting a MaskEdBox enabled=false makes
the text gray, and that's unacceptable. And they want
right-alignment, especially of dollar values.
For the read-write fields, they want right-alignment,
at least when the control does not have focus.
Looks like a very easy task for two controls in CSTEXT.VBX, the
CSDouble and the CSCurrency. They have a "DisplayOnly" property
distinct from the "Enabled" property, and a "Justification" property
(though why the latter isn't named "Alignment" and why it stores
[0, 1, or 2] in the .FRX file are complete mysteries to me)
So I began the conversion.
A few days later, everything began to unravel.
Unfortunately, if CSCurrency is bound to a value of type double, such
as a query calculation, and the number is very small, for example
"$0.0000001234" (1.234E-7), then CSCurrency incorrectly displays "$1.234"
Clearly a bug.
Crescent tech support, in the person of Robin Cohoon, admitted:
"There is no way to get the double control to
diplay a $ symbol and the currency control will
not read scientific numbers and do the conversion."
In further email, she tried to be helpful, but didn't seem to be able
to understand that I MUST bind to a database and can't afford ten lines
of code for every one of the dozens (if not hundreds) of controls in
my project. Any suggestion that includes "put this code in a click event:"
isn't much good in the real world.
So, CSCurrency is worthless. It can't be bound to a query result
and be expected to show numbers of even the correct order of magnitude
if the result is nonzero but so small that zero should be displayed.
I could write some code, for EVERY control I instantiate,
but should I have to?
Next, my users begin to enter some test data, and all the reports
start turning up blank columns.
It seems that CSDouble writes a null to the database when the user
enters zero, and nothing I have tried will make it write the VALUE of
zero to any database field.
Unless that can be fixed, CSDouble is, also, worthless.
Did these guys TEST anything?
Did any users every really BUILD anything with these?
Crescent have not responded to my further inquiries. Well, OK, so
I haven't given them a lot of time, but my three month project is now
weeks late, and (after Crystal Reports) Crescent is the second leading cause.
I'll leave the horror stories about their OCX package, such as unexplained
shipping delays measured in MONTHS, for some other post.
Can anyone (even Crescent) suggest some bound controls that can do
these things? I have a firm requirement to minimize code, so any
solution that requires more than a couple of lines per control,
or can't be executed in the change event, just isn't acceptable.
I'd sooner give up the right alignment, and go back to using
pairs of MaskEdBox & Label controls for read-only. I hate MSMASKED.VBX,
it's so weak, but at least it reports actual values and can write
a zero to the database.
Maybe it was "PDQ" rather than Crescent, all along, that I liked.
Whatever that character string means from them...
PDQBasic, and PDQComm did everything I ever asked from them, and
did it well. I bought QuickPak, and later the PowerPaks, on the
strength of that history. I still hope Progress/Crescent can
prove to me they deserve something better than to be slammed.
Bob O`Bob
--