3 Replies Latest reply on Oct 29, 2013 2:26 PM by philmodjunk

    Value lists don't update depending on how field is selected



      Value lists don't update depending on how field is selected


           I have a script that I run OnObjectEnter for a bunch of fields. It sets a global field to a predetermined ID based on the field you are entering. This ID is used in a relationship to determine what values from a related table should be shown in a value list in the field you just entered. So for example:

           Enter the zip code field -> script triggers, sets global ID field to "zip code" -> the zip code field's value list shows the appropriate zip codes based on this relationship.

           This works fine when I am tabbing between fields, as soon as I tab to a field the global ID updates and the correct values are shown. However, if instead of going straight from one field to another I deselect all fields and then select another field, the script triggers but not before the value list is displayed. This means that if I click in to the zip code field, deselect all fields, then click in to the city field, it shows a list of zip codes. If, however, I tab from the zip code field to the city field, it correctly shows a list of cities.

           I apologize if my question is confusing. I'm not sure if the problem is in how OnObjectEnter is triggered, or in how value lists are indexed. I have a workaround with a script step that takes the focus to a different field, and then back to the one you just entered, which works but seems sloppy. Thank you for any and all help!

        • 1. Re: Value lists don't update depending on how field is selected

               I'd like to know exactly how you have set up your value list if you are getting a list of zip codes in the city field. That seems like a needlessly complex way to set up a conditional value list given that there are simpler alternatives.

               The fact that a list of values deploy and the user can select an value before the OnObjectEnter trigger performs its script is a known limitation of this script trigger. You may need to try this approach:

               Put a field in front of the drop down list field--it can even be a copy of the same field. Remove the drop down list field from the tab order and replace it with this field placed in front of it. Remove the "arrow" option if you have specified it. Now set up your script trigger on this new field object to set your global field, then use go to field or go to object to put the focus in the field with the drop down list format to deploy it.

          • 2. Re: Value lists don't update depending on how field is selected

                 Hi Phil,

                 Thanks for responding to me again, your workaround sounds smoother than mine.

                 The reason I am basing the value lists on a global value is it allows the single relationship on the bottom of the attached screenshot to do all the work of the top four. This also means I have one value list, rather than four.

                 It seems that reducing table occurrences and overall schema should be a good thing, however perhaps there isn't any benefit to what I'm doing given that it requires an added script step every time you change fields.

            • 3. Re: Value lists don't update depending on how field is selected

                   Do you really need any table occurrences at all for your value list?

                   If the only match field needed is the one that identifies whether the data is for a zipcode or a city name, then you don't need any relationships to support your value list function--if you define a different value list for each field. The only way a relationship would be used for your value list function is if you specify an additional value list for filtering the values--such as seeing a list of all zipcodes for a selected city.

                   And if you mean that you need to reference or lookup data in the value list based table on your layout, then a much simpler data model can be setup that reduces the number of table occurrences and there are also ways to use ExecuteSQL to access the related data that reduce the number of table occurrences needed.