Upgrading A Solution That Has Valuelists

[SteveB]

I think I know this can't be done, but here it is anyway: I have a bunch of valuelists that I store in a preferences file, where I give the user the ability to change the list contents by including the format option Edit... If I have to replace the preferences file because of an upgrade or major bug, there doesn't seem to be a way of transferring these valuelists to the new file. I know I can get them out with a Design function, but how can I put them back into the new file???

[djgogi]

I know it's easy to say, but you should use lists from records instead of hardcoded values. It meens that you should also provide methodes (like scripting) for inserting/updating them. Never give user oportunity to edit directly the value list ( he/she might delete some very important information)

Now, if you are interested on how to change hardcoded list to list from values from relationship, here's the method.

Create an new file called List.fp5 with following structure

listId

ListName

parentID

ListItem

isItem

(you could extend this structure to allowing multilevels)

Now populate this file using looping script and design function for extraxting individual values from your lists and redefine your lists.

HTH

Dj

[SteveB]

Not to belittle your suggestion, but that is pretty ridiculous. These are valuelists the user himself creates and maintains. I don't care if the list is empty or has 100 items. And I have quite a few of them with Edit... enabled. Another shortcoming of FM, because I should be able to build a valuelist (with any options) under script control. They gave us the ability to get the lists out, but not put them back. Stupidity reigns!!!

Sorry, it's my afternoon for ranting!!!!

[BobWeaver]

Steve

I replied to this post last night, but it seems to have disappeared. Anyway, my suggestion was to use valulists based on fields in your preferences file. I don't know how your preferences file is set up, but it shouldn't really matter.

The main thing is that while I would create a field for each valuelist, I would use only a single record for each one. That way the user can edit the list, but is only working on a single text field, just like editing a regular valuelist. As long as each item is separated by a carriage return it will work. Then, you can control access by scripting, and automatically import the existing valuelist items when you do an update. If you don't like the idea, feel free to rant. I'm fairly thick-skinned.

[SteveB]

Bob:

I have lots of layouts that have City and State valuelists that the user has the ability to change. Also, quite a number of other valuelists that can be edited. How do you handle giving them the ability to add to a value list? Given that your technique requires a script for each changeable list, do you put buttons next to each field that is editable? (I've got City and State fields butted up against each other). I guess I'm asking what do you do visually? I don't want a layout that just handles changing these lists.

Also, since the preferences file would now require a record, will the record always be the found set (do I have to do anything to make these valuelists appear)? The user in my solution (Kiosk) never goes into this file..its fields are always referenced from layouts in other files.

Thanks, Steve

[BobWeaver]

I would create a single record in the preferences file with a field for each valuelist. Make the fields accessible from the main file via a constant relationship. Put the valuelist fields on a separate layout. When the users go to that layout, they will see the valuelists and can edit them. You can control access to these just like any other layout.

You only need a script when you want to update the solution. You just use the script to import the old valuelist items from the old prefs file into the new one. Other than that, I can't think of anywhere else that you would need a script.

[djgogi]

Steve,

always read twice before replying.

If my suggestion was so ridiculous how it happened that you have this problem with upgrading; I don't have it and I'll never have it. Why?

Maybe because I never use "custom values" option for value lists that are pretty obvious to be modified by user.

This kind of value list is for items like male/female, yes/no/dubbious.

I always have an entity List or Categories, where I give user opportunity to do whatever they want with list items :create , disable/enable, delete.

You said that you don't mind if those lists are empty or contain 100 values, if so than tell your users that they'll have to reinsert all those values manualy ( who cares, they are empty or at least they might have inserted only 99 values)

I'm agree with you about lacking of the "import" feature for valuelists but do you intend to say that you didn't know it before starting the implementation of your project?

However I, also, gave you the hint on how to change (almost painlessly) the structure of your preferences file.

If you missed it, the redefinition of valuelists occurs only in the preferences file!!! not everywhere they appear in your solution.

Dj