I have records identified by a string like A.1.99.
I want A.1.99 to sort before A.1.100.
I have chosen to achieve the sort sequence by storing the string with lead
zero padding - A.001.099 - but displaying it without the padding.

The approaches I can see are:-

Use OnGetText and OnSetText to hide the underlying padded string from the
user interface so the user only sees the short version.

Use a calculated field which is the shortened version of the padded field.

Use two fields.  The user interacts with the short field and a BeforePost
handler expands the short field into the long field.

I can't make my mind up which is the least "nasty".

There will only be one place where the user can edit the field, but
several where it will be seen, including queries based on this table.
Am I building problems for myself?

--Bill Sparrow--

Bill


I know it wastes space, and duplicates data but I'd go for the two field approach. That way you only have one location in your code to bother about.

Having said that I'd prefer to get the user to accept seeing and using the padded version.

Roy Lambert

I'd go for the padded version including a check on
data entry to make sure that it is padded out.

I have a similar situation and even if the user enters the unpadded
version it gets automatically converted and displayed.

Jon

Roy Lambert wrote:
> Bill
>
>
> I know it wastes space, and duplicates data but I'd go for the two field approach. That way you only have one location in your code to bother about.
>
> Having said that I'd prefer to get the user to accept seeing and using the padded version.
>
> Roy Lambert
>

Thanks for confirming that at least I am not missing an obvious trick.

I'm heading down the two field route at the moment.  Getting the customer
to accept the padded version on screen may be acceptable.  I will put it
to him.

The end result of the application, however, is a printed document in which
these strings appear as paragraph numbers in the traditional multi-level
style of nested numbering.  So I need to do the trimming somewhere, either
on data entry, or in the reporting.

--Bill Sparrow--

Bill,

A little late to the discussion, but I would use one field,
automatically padded/formated correctly for sorting when saved. The
TField.OnGetText event is a very powerful tool. Once you have the padded
value saved, you can use OnGetText to display it in the padded or
unpadded form for grids & controls. You could even have a global
variable to allow the users to choose the option they like best.
OnGetText also controls how the value will display when editing or
displaying in a TCustomEdit descendant. If the data is only in one
place, there is no chance that the displayed copy will ever get out of
synch with the real data.

Good luck no matter how you do it.

Sean

bsparrow@cix.co.uk (Bill Sparrow) wrote:
> Thanks for confirming that at least I am not missing an obvious trick.
>
> I'm heading down the two field route at the moment.  Getting the customer
> to accept the padded version on screen may be acceptable.  I will put it
> to him.
>
> The end result of the application, however, is a printed document in which
> these strings appear as paragraph numbers in the traditional multi-level
> style of nested numbering.  So I need to do the trimming somewhere, either
> on data entry, or in the reporting.
>
> --Bill Sparrow--
>

I'm with Roy: I recommend the use of two fields, which is what we do in our
congressional app, one field formatted for use as a collated key field in
indexes and the other for display and edit purposes. This way the conversion
overhead is taken once when the record is created or edited, not everytime
it is referenced (in reports, e.g.). It also simplifies both the code and
the appearance of the code and therefore the maintenance of that code.

Just my opinion.

Jerry