As I understand it from my reseller, you are correct. In general, we only use lists in template cards. You could test it by adding something to a list, selecting it in a card, delete from the list then edit the card and see what happens.
Thanks for your quick reply.
I will test as you recommend.
I really need to understand how these lists work.
Another idea is to use an Alias list type. Change the list under "List (for cards)" to type of "Text with Alias"....then make sure the Alias column has all the old names you used. Then in the "Displayed Value" you can show whatever you want, even change it in the future. Just keep in mind that the Alias is what is actually stored in the database....and alos pushed to file properties if you have it mapped to do so.
The value hasn't changed but since a matching entry no longer exists in the list, nothing is displayed in the droplist control. You have a couple of options that I can think of.
- Use a combobox control so that the value can be displayed even though it is no longer in the list
- Add a edit box control directly on top of the droplist control and make it read-only
The downside of the first option is that a user could enter a value that is not in the current list. That is why I came up with the second option. It's a bit tricky getting the controls lined up and it looks a little bit funky, but it works.
Combobox did not work. The values in the datacard blanked out when I changed the list values.
I had to leave the existing values in the list, and add the new entries to the top of the list.
Not what I would like to do since people can still pick from the old entries at the bottom of the list.
I really don't understand why the values needs to be in the list if the database has saved the values to variables.
I am not sure about your second option. How do I ensure that the user is selecting the combobox and not the read-only droplist?
It is very annoying that users have to go through these lengths to make the software do what we need.
More often than not, it seems like the tail is wagging the dog, rather than the dog wagging the tail.
I have not had a chance to try edit box over the droplist.
This sort of details is starting to really eat up my time!
Michael is on the right track. What occurs with the drop list is that if the variable has stored a value that doesn't match the list then it will show nothing. You could set it to "History" and it may then show any previously entered value. Of course it may only apply to previously entered values since you've switched to Special Value: History.
However, the real way to know is to check the preview tab on the right where the variables are shown. Even if your droplist box is empty the preview tab will show what value is stored. This is why the edit box is a nice idea because it simply shows what is stored without needing to match it to anything.
Let us know!
Check out this post at InFlow-Tech.com
The list functionality described there doesn't run off of a static text list that you maintain, but rather creates the lists based of whatever values exist in the vault. It reads all of the existing values for a variable and uses that information to populate the drop down list. That way, you are able to create new values for the list, but if an older value still exists somewhere in the vault then it still exists in the list. It may not be what you're looking for exactly, but it may help stop the tail from wagging the dog.
Derek M. Lawson