Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General Discussion » View Thread |
Messages 1 to 6 of 6 total |
Sort order for strings like A.1.99, A.1.100 |
Fri, Nov 10 2006 7:27 AM | Permanent Link |
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-- | |
Fri, Nov 10 2006 8:40 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Fri, Nov 10 2006 11:59 AM | Permanent Link |
Jon Lloyd Duerdoth | 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 > |
Fri, Nov 10 2006 1:11 PM | Permanent Link |
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-- | |
Fri, Nov 10 2006 2:53 PM | Permanent Link |
Sean McCall | 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-- > |
Fri, Nov 10 2006 4:21 PM | Permanent Link |
"Jerry Clancy" | 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 |
This web page was last updated on Tuesday, April 30, 2024 at 03:55 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |