As far as I know, there is no way to import custom value lists.
The standard solution is to use a table and base the value list on that.
yes Mike that's what im currently doing but it sure clutters up my list of tables and ER graph.
anyway so be it so thanks..
Normally you shouldn't need more than a few hardcoded value lists for the UI (most notably ”Boolean” with 1).
The other values that are typically crammed into value lists are usually entities anyway (which some people find out to their chagrin a bit too late; usually at report-creating-time)
As far as the Graph is concerned, it's usually possible to minimize the TOs and push them off in a corner somewhere.
Can't do much about the table list, though. Maybe you can manipulate the table names to shove them down towards the bottom (start them with "zz_" or something).
Or use one table and add a valuelist_key or the like so all values can reside in one table, then fetch them relationally or by SQL.
You might be able to use the design function that can be used to put the values in a value list into a variable than set a field in a 'value list only' table to that value and reference that field in a new value list. Or something like it...
Having a value list table containing many fields as mentioned by others can work really well for some purposes (especially concerning settings and user preferences etc. It prevents clutter with regards to table occurrences and is easy for the end-user to edit. Each field can contain as many rows as you like - that way, a single field in a single record determines the entire value list, and a single record can be used to create and customise as many value lists as you like.
I think there *is* a way to import value lists; provided you store the list values in a table. Then, just import the table via an import script.
I was faced with the same situation and I just place an icon next the main layout field that shows the value list when entered. By clicking the icon I run an script that opens a window and brings in a layout based on the VL table. The user can edit, add, delete or print the list. No Problems.
Hope this helps.
There are numerous types of value lists. The ones that could be imported are the ones where you enter the data manually such as orange, apple, pear, etc.
Then there are valuelists where the data changes as records are added or deleted from a table. There you would want to import the pointer to a table which is now in another file.
You also have valuelists that are pointed at a field in a table. Actually this is a field number in table number situation and this won't be the same in your new table.
Then there are conditional value lists whose value is determined by a relationship with another table, again the numbering situation.
And there is more if you study the types of value lists you can create.
You may find that many of the existing ones aren't being used as often in the process of development the lets use another value list occurs but that layout gets deleted but the value list remains.
I've added this because sometimes it helps to gain an understanding of why something isn't done plus the possibility that it may not be needed that much even if when it is the need is great.