Trevor asked:
> ...and I'm sure that I'm not the only one.
Your not 8-)
> Is it just me, or is any decent entry field necessarily descended from
> TCustomControl? Hey, is TCustomControl even a good place to start?
TCustomControl is the perfect place to start building your own collections
of edit controls that work exactly as you want them to. The Profax team
has built replacements for every single data entry control we needed for
our accounting package, and we have not regretted it one bit.
> So far, I've some good entry field controls working. They
> exhibit none of the "why does it do that?" kind of behaviour
> that inbuilt Windows descendants have. Several have popup-
> helpers (also descended from TCustomControl) like calendars,
> numeric keypads etc.
Ditto, once you toss the baggage of the basic windows controls you have
complete freedom to innovate and create control that perform things that
would be impossible with the basic windows controls. People should
remember that the basic windows controls were written years ago (Windows
3.0 or earlier), were not designed for serious business data entry, and
have not been changed much over the various windows versions.
> Problems to date that I think someone else may have solved are:
>
> a) Helper controls show up when some kind of focus rule is imposed, but
> since they almost always have their parent handle set to 0 ( with
> Windows.setparent( helper.handle, 0 ) to avoid clipping, they actually
> appear as a blank button on the taskbar! Does anyone know of
> an easy way to avoid this?
We keep the our popup control parented to the editor, and clear the
WS_CHILD style bit and set the WS_POPUP style bit so that the control
appears to float over the top of the rest of the application. This works
perfectly for everything that we have wanted to do so far.
> b) Some of the helpers are swallowing keystrokes...they
> respond to WM_CHAR and WM_KEYUP messages, and set Msg.result
> appropriately, but other keyboard handlers in the near
> vicinity ( Form.keypress etc) don't seem to get a look
> in, AND ITS ONLY SOME KEYS AARGH!
You have to be careful here, as many keypresses are intercepted by Delphi
and used for navigation. Have a look at the event loop and associated
routines in Forms.pas, because lots of keys eaten in there. We solved this
issue by having our own hierarchy of control process the CM_CHILDKEY
message which is automatically passed from child control to parents until
processed, and allows correct "overriding" of default keyboard behaviour
during extended editors getting keys and the like.
> c) Double-clicking somewhere in a helper (this is a TCustomControl
> remember) seems to set some kind of focus flag somewhere, so that if the
> helper contains other controls, _one_ of them will receive all mouse and
> keyboard messages, whether or not it is vaguely interested in them.
The problem here is that from Windows point of view there must a window
(that is a window Handle) that is the current focused window for key
presses. So you have a choice of how to build your controls, either have
your helper window passed unneeded messages up to their parent for correct
processing (see CM_CHILDKEY comments above for some of the solution), or
build you helper control from descended TGraphicControl, not
TCustomControl.
By starting at TGraphicControl you are creating controls that don't have a
windows handle, but can be parented to a handled control and these provide
the helper visual appearance, don't grab the focus, and are very elegantly
supported by Delphi.
> If you've been there and solved some of these
> problems, I would love to know either i) that you did it (and snicker
> snicker aren't letting on how) ii) that you did it and here's how,
EMail me if you want more advise on how we replaced all the Windows
control, because it possible, we've done it, and its part of the
competitive advantage our software has over the other products in our
market place. When you compare control designer for accounting data entry
to what you can build based on the Windows controls you can really feel
the positive difference in the ease of data entry, and the programmer's
are happy because we can fix any problems, and enhance the controls with
very minimal effort now.
> or iii) its impossible, give in and let M$ control the world,
NEVER!
> iv) that there is a project somewhere wherein Delphi developers can
> create controls that actually work and I should be contributing,
Not that I have ever heard of.
> v) that there's actually a good library available out there somewhere
> (source included) which does this stuff.
We looked and gave up. All other libraries start with the basic windows
edit control (usually from TCustomEdit) and try and add all the features
that are necessary. To do this you have to work about some seriously
perverse design issues with the basic Windows edit control, the crap
Windows default keyboard handling, and if you use data-aware control, the
seriously weak access provided for before and after change notifications,
good data validation and correct error handling.
So in the end we have spent about two man years building a full set of
data entry controls that meet our exacting requirements, after first
trying to go the buy it route and having all our work fail due to our high
quality levels. Now our grids, editors and navigation controls are
perfect, and the windows tree control is under heavy threat of replacement
due to too many weirdness's.
Cheers, Max.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
