Anyone out there give their users the ability to use aliases for the field names? If so how did you go about it?

I'm building a skills / competencies matrix system and everyone seems to use different terms for each level.

Roy Lambert

On 24/06/2016 9:39 p.m., Roy Lambert wrote:
> Anyone out there give their users the ability to use aliases for the field names? If so how did you go about it?
>
> I'm building a skills / competencies matrix system and everyone seems to use different terms for each level.
>
> Roy Lambert
>

Hi Roy

I haven't done anything about it, but have thought about doing something
similar.

It occurs to me that you could use the "Description" field in the
Information.TableColumns table.  You could allow users temporary
administrators privileges to allow an ALTER TABLE statement.

In your code, substitute label names and grid headers using something
like the SQL below

SELECT COALESCE(Description,Name) AS "Label"
FROM Information.TableColumns
WHERE TableName = 'MyTable'
  AND Name = 'MyColumn'

Put (say) '{%Skill' in the label or column.title.caption.  At form
create, run through all components looking for captions starting with
'{%' and substitute the text.  (I do this scan through components anyway
to adjust column widths and order in grids.)

Having typed that up ... why use the Information.TableColumns?  Just use
a straightforward table.

Cheers

Jeff

Jeff


Thanks for that - its going pretty much down the approach I was thinking of. I'm also going to see if there are any freebie internationalisation packages around.

Roy Lambert

Roy,

<< Anyone out there give their users the ability to use aliases for the field names? If so how did you go about it? >>

Some customers use the Description attribute of columns for such purposes.  If you turn on this property, then EDB will use the description for field labels:

http://www.elevatesoft.com/manual?action=viewprop&id=edb2&product=rsdelphi&version=XE&comp=TEDBDataSet&prop=AutoDisplayLabels

I would imagine that the descriptions don't change very often, so it's not like you'll be altering the tables often.  Plus, it only affects the database catalog, and not the actual table files.

Tim Young
Elevate Software
www.elevatesoft.com

Tim


Thanks - I'd forgotten that one.

Roy Lambert

Roy,

What I have done in the past is to name the fields like NValue1, NCaption1, NValue2, NCaption2, NValue3, NCaption3 (where "N" is the general description of the field...like BackgroundValue1, BackgroundValue2, etc.) and then I allow them to change the caption of the label of the field. I use the Input Dialog Box to have them name the caption and I save that in the database under the NCaption fields. When the form is created I use the caption field data to populate the captions.

I have been successful in doing this. The highest number of fields I have done this with is 20 (not including the corresponding 20 caption fields).

Jan


Roy Lambert wrote:

Anyone out there give their users the ability to use aliases for the field names? If so how did you go about it?

Roy,

I am not sure about using the system-field "Description" in the way you describe. Perhaps I haven't exactly understood your requirement.

I had a phase of using the "Description" field, but found there were a few draw-backs. These may not be problems in your use-case:

1. All edits/updates require full locks of the data-table, as you are changing system meta-data. This makes it hard to update any system that is permanently live.

2. All edits/updates create changes to the catalog of the database, meaning that some backup / restore and update / replication processes are more complicated if you are changing field Descriptions.

However, if you are talking about a once only change for each system, i.e. in the installation phase, after which users would not change it again, I think it would work well.

Adam,

<< 1. All edits/updates require full locks of the data-table, as you are changing system meta-data. This makes it hard to update any system that is permanently live. >>

I just looked at this and you are correct. However, this is a bit of a bug, because EDB *shouldn't* be locking the table when only the descriptions are changed (it definitely knows).

I'm doing a new build soon, and I'll include the fix for this in the new build.

Tim Young
Elevate Software
www.elevatesoft.com

Tim

That would be super cool.

I have pulled back from using the Field.Description because of the issues with updating requiring a full lock.

It would be great to be able to use this as a feature.

I would actually like to put in a user-editable Field.Description, so that managers can add explanations / help relating to the field for staff using it.

Adam