Rohit Gupta said:
> Your view (or indeed anyones) of their code and facilites is coloured
> by your own experience. My (and people such as Paul Lowman, Max
> Neilsen and Paul Heinz) maybe far greater in that respect.
^
FYI: its Nilson, and I thought that being invoked I should reply.
> My users demand more from my windows system than they had in my dos
> system. I cant give it to them using standard components. Heck, I
> cant even do it with all the libs out there. And others (including
> the few named above) have gone to great pain in duplicating and
> fixing most of VCL). They didnt do it for fun.
and Max Renshaw-Fox replied:
> The point I was making was that the VCL does what it was intended to do,
> which is clearly less than some people want (which is why Max et al have
> had to "fix" it) - but still what was intended and, arguably, what the
> majority of Delphi users need. That may make it a commercial solution,
> rather than a technically pure one - but not a childish one.
We (That is Paul, Ian and myself) have replaced large chunks of the VCL, and
the reasons behind doing this fall into two four categories. As far as I'm
aware anyone who starts trying to build complex business solution in Delphi
is going to strike problems in these areas, so I'll talk a little about each
in turn:
Problem 1: Microsoft common controls.
-------------------------------------
All of the basic editing controls (TEdit, TComboBox, TCheckBox etc) are all
just object wrapper about the original (and we're talking Windows 3 or
earlier here!) Microsoft windows. Once you start working these hard and
asking them to perform stuff that they were never designed to do, then you
hit problems. Big problems are in the ares of subclassing, adding extra UI
components and embedability into grids.
The VCL wrappers do a good job, but if you want more from your controls then
you need top replace these completely. And by this I don't mean using
InfoPower, because all of their controls are just more wrappers over the VCL
wrapper over the MS windows controls. If you read their code and then start
trying to extend the controls even further things break in really exiting
areas 8-(
So the Profax team wrote an entire set of replacements for all of the common
editing controls, and they use no Microsoft control at all. Now the controls
do what we want and can be extended rapidly and easily in any direction that
is needed.
Problem 2: Data-awareness issues.
---------------------------------
After three years of working with data-aware controls I have still not
really decided if the design is correct or not. Danny Thorpe (Senior
Engineer, Delphi R&D) in the borland.public.delphi.vcl.components.writing
wrote yesterday:
> One thing I've been wanting to tackle since the day the interface syntax
> was sussed out (pre-D3) is reworking the nature of "data awareness".
> If a TEdit implements an IDataAware interface, then it can be bound to
> database fields. The interface could even be implemented by satelite
> helper classes that "attach" themselves to the TEdit instance, so that
> TEdit itself has no knowledge of the database stuff.
So I'm not alone in wanting a better way of building data-awareness into
controls. So unless your prepared to go completely non data-aware, something
that would quickly drive me insane, or force me to essentially duplicate the
entire data-aware mechanism, you must use the TDataLink and TFieldDataLink
interfaces provided.
The main problem with the existing interfaces are those of navigation
between controls and cleanly handling invalid data entry situations. If you
have ever tried to build a idiot proof interface using the existing
data-aware controls you quickly start to hit nasty problems in these
transition areas. The biggest transition problem is that all of the
data-aware stuff fires in the DoExit code, which itself is inside the
WM_SETFOCUS processing, where you have some severe restrictions on what you
can and cannot do.
So the Profax teams controls have to jump through some burning hoops to make
sure that weird errors don't occur and confuse the users.
Problem 3 Keyboard handling.
----------------------------
The standard Windows keyboard handling is broken in one major way. That is
that the WM_KEYDOWN event is first prepatched furiously because of the
stupid Windows design, and then sent to the active window which must handle
anything thrown at it. I see this a lot on the Delphi news groups, people
furiously using TForm.KeyPreview in an attempt to handle keypress before
controls eat them, and to do the VK_RETURN is a VK_TAB thing.
Ian Farquharson realised that the CM_CHILDKEY behaviour that the VCL adds to
the entire grubby keyboard handling process was exactly what we should be
utilising instead. From Delphi 3 onwards Delphi sends a CM_CHILDKEY to the
focused windows, and that window can either process the key or pass it up to
its parent. That control can then process the key or pass to its parent and
so on. The upshot of this is that you can provided extend the keyboard
interface cleanly in a container object and be sure that keypresses will be
see by it even it sent to a child window.
Add to this a capability to 'hook' into a controls child key handling and
you then have the capability to design components that can be dropped onto a
form to provide additional keyboard behaviour with minimum costs.
Problem 4 The standard TCustomGrid.
-----------------------------------
The Delphi TCustomGrid and all descendants are extremely complex components.
Unfortunately they have one or two minor problems that can start to become
major problems. The two issues that annoyed us the most invoked an extremely
obscure bug in the TDataLink notification mechanism, and with the
limitations of the in-place editor mechanism. Most people are recommended to
just use InfoPower and go away, but IP is based on TCustomGrid and inherits
all of the same basic problems.
Danny Thorpe also commented yesterday:
> I'd love to have the time to engineer the extensibility that TDBGrid and
> TGrid should have. Ask anybody who's been in my office, the TDBGrid
> extensibility item (installable cell editors, for example) has been on the
> whiteboard (diagrams and all) for years. It's permanently set in the
> whiteboard - it won't erase if you tried! It's a little difficult to get
> management to let me run off on this sort of tangent for 4 to 6 months
when
> the result, while technologically superior, would provide few direct
> benefits to DBGrid users.
Again I'm not alone in finding that for certain applications the TCustomGrid
just doesn't cut it.
So the Profax team has written their own specialised data-aware grid that
does exactly what we need, but is not useful for much else. Its certainly
not very extensible like the TCustomGrid is, but its does what we need and
provides a rock solid component to use for our applications.
Summary
-------
I know that you could write a commercial application using just the VCL as
it ships. It would match most of the other stuff on the market for user
interface, speed and useability. As Danny pointed out, there is no market
for a Delphi that just had better controls, so its not going to be done by
Borland. What the VCL provides is good enough to sell Delphi, and for people
to use.
But if you want to be better than the competition, faster, easier to use,
and to have a world class Rapid Application Development environment to do it
in, and to be able to debug and fix any control problem that arise, then you
must start to replace or improve all of the above parts of the VCL.
That why we have replaced as much as we have. The foundations of the VCL are
rock solid, otherwise we would not be using Delphi, but some of the
structure erected on this base are not as earth quake proof as they could
be.
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
