Neven MacEwan said:

> Jeremy

> I use ADO and bound controls - I think 'people' use unbound control
> 'cause they can't get bound controls to work the way they want.

> I take Max's approach - don't work around the problem (by unbinding
> your controls) - SOLVE THE PROBLEM

Assuming I'm the Max refered to here (as opposed to Max Renshaw-Fox) I can
chip in with a bit about whete we found that "raw" data-awarea control
fall down.

The main issues that we had with data-aware controls for use in our
accounting product was the extremely minimal notification and contro lyou
had over the actual data entry and validation process, and the rather
stupid duality forced into your control design by the implementation of
data-awareness.

The first issue of insufficient notification of changes we solved by
having a standard base data-aware class that provided a mass of extra
events that were fired off during the TFieldDataLink.UpdateData
processing. These included:

  BeforeUpdateRecord
  DoConvertText(Text, NewValue)
  DoBeforeSaveValue(OldValue, NewValue)
  Field.DoBeforeChange(NewValue)     // Hook down into data module
  Field.DoAfterChange(OldValue)      // Also into data module
  DoAfterSaveValue(OldValue, NewValue)
  DoAfterUpdateRecord

This was all possible user interface points of interest can be hooked by
decendant control and various OnXXX event handler, plus extra validation
that belongs doen in the data modules (as opposed to the form UI layer) is
hooked as well.

The extra data-module hook is needed because the standard TField.OnChange
event is a little little so simplistic and has lots of missing
information.

So no now matter what the rule (eg. "negative values change the font to
red" or "negative values are not modified by GST" we can hook at the
appropiate level to do the job with minimal extra work.

The second issue of having to have one control for non-dataaware editing,
and a second for data-aware editing and wanting a unified UI for both was
solved by making all controls be both and having an internal flag that
switches a control from one to teh other. The flag is only twiddled at
control create time for snaity sake, but this does provide us wit ha
unified control set that is much quicker to maintain than one like
Delphi's base classes where there is a split between Control and
DBControls.

Cheers, Max.


---------------------------------------------------------------------------
    New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
                  Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED] 
with body of "unsubscribe delphi"

Reply via email to