Carl Reynolds wrote:
> The grid sounds good. To you: are you considering marketing it?!
There are two main problems with marketing any Delphi component from our
experience. One is that the time to properly document a component is fairly
long, almost as long as it takes to write them. The other is in having
enough time to spend actually marketing the component, that is, placing it
on all the Delphi sites, sending news messages to the most useful places,
trying to get people to link to your sire etc. Then you also need to
consider the technical support costs as an on going thing for the company...
Because Profax's focus is on products rather than components it become very
hard to justify this kind of money for the pitiful returns that can be
achieved. We are open to offers to handle the documentation and marketing
for us from anyone who can provide good references in this area.
> I mentioned reinventing the wheel. What is more cost effective - to
> spend two weeks developing a whizzy new generic component which you have
> to maintain in-house, or to "waste" a day trawling the web, only to find
> a component that does all you want and more, for a mere U.S. $100? We
> made the mistake of doing the former before doing the latter only once,
> and development and maintenance of our component cost a lot of pain and
> effort. Now we look for other components first.
Our experiences have been the opposite in this area. After trying a couple
of the major component libraries, and accessing many of the shareware code
our opinion was that most of the Delphi components available were just not
good enough.
As I mentioned in my first message most of the third party components are
just incremental improvements on the existing Delphi components (and so
inheriting all of the default Windows control stuff that we don't like), or
are wrapping some Windows control better or differently than Delphi does.
As the Profax teams primary contention is that the underlying Windows
controls are bogus enough to warrant replacing the 99% of the third party
stuff is not much use to us.
Now in if two weeks I can implement an entire new data-aware grid that has
more features, less bugs and is smaller and simpler than anything else out
there then we regard this as *saving* money in the long run. We *want* to be
able to maintain the code in house, because that means that if (Zharquon
forbid!) a customer find a bug, then we can fix it instantly and not have to
worry about mailing component authors (who may or may not do anything),
maintaining patches on other people code and hideous versioning problems
next upgrade.
Now I'm not 100% against third partly libraries, but our experience so far
has gone like this:
Infopower 2/3: Just wraps existing Delphi code (and badly in my opinion),
has so many bugs and warts that we gave up trying to fix them, and the code
after being hacked over and over from Delphi 1 -> 2 -> 3 -> four is so
cluttered as to be almost san scrit like.
QuickReports 1/2/3: After fixing dozens of bugs, and notifying the
authors )and getting no response or fixes in new code!), and running into
terrible design flaws we gave up.
AdRock components: Again just wrappers extending existing Windows controls.
Inherit all the behaviour we don't want.
All of these products now sit mouldering on our library shelves and will
never be used again. The only two third-party products that we actually do
use are:
RP Pro 3: Gets the thumbs up for good coding, responsive developers and a
perfect feature match for what we wanted to do, that is automatically
generate reports because actually writing reports that a good component
could write for you is the most boring, time wasting and costly exercise you
will ever encounter.
IB Objects: Jason Wharton provided a very nice connectivity layer to
Interbase and we worked closely with him to get it working perfectly. Jason
has now wandering off into doing custom component development on top of the
connectivity layer so we as getting tempted to do a rewrite of the low
levels of the code that we use and dump having to maintain installed
versions of all the rest of the code.
> So you won't be marketing your grid then. Too bad. I find TopGrid's
> generic grid a bit of a pain to use and could do with something simpler,
> for the special cases where I don't want to use Infopower or Orpheus's
> grids. But anyway, it'll do in the meantime. :)
As I said the cost verses return on component marketing is a problem. Also
our grid is closely tied into a lot of our other code by assumption. For
example we only have a data-aware grid, because if we need to do non
data-aware grid stuff we just throw the information into a one or our memory
tables and use the data-aware grid and data-aware control with all the
funkly data validation mechanism we have engineered.
Perhaps one day we will be able to sell the entire suite, but unless you
want to talk real money with us our components must, per force, remain in
house.
Cheers, Max.
========================================================================
Max Nilson Phone: +64-9-278 4931
Profax International Limited "Most people would rather die than think
use Std_Disclaimer; - in fact, they do so" Bertrand Russell
========================================================================
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
