> > It's still the best option
> > available...
>
> This I don't necessarily agree - it might be the best option for a quick and
> dirty hack, but if I was to design the application, I would use an business
> object model and make the combobox list a view of the data only - so your
> business logic code is not dependent on the UI.
Exactly and for mapping ID's to textual information this works as a fine method...
type
TFindType = (ftNAME,ftID,ftAREA,ftGENDER,ftEMPLOYER);
TFindTypes = set of TFindType;
const
FindTypeNames :array[TFindType] of String = (
'Name','Id Number','Geographical Area','Gender','Employer');
procedure GetStrings(SL :TStrings);
var
I :TFindType;
begin
SL.BeginUpdate;
SL.Clear;
for I := low(I) to HIgh(I) do SL.AddObject(FindTypeNames[I],TObject(I));
SL.EndUpdate;
end;
Now UI issues like sorting the list do not impact the validity of numbers as they
TFindType enumerations. Also Textual changes do not impact as data is stored
as the enumeration value. Likewise a DB stored list can be loaded in and IDs in
processing code and UI code are identical... I don't really see much fault in my
suggestion that the Casting technique as opposed to a single field 0-behaviour
class is the best available for the task of storing a single value and string together
in a standard UI element...
The biggest 'BUT' is to confirm with certainty that there will only ever be a single
value associated with each string - otherwise it's better to build a class - and
possibly a class collection (since features like multi-tier sorting aren't available
in the UI controls)...
--
Aaron Scott-Boddendijk
Jump Productions
(07) 838-3371 Voice
(07) 838-3372 Fax
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
