3 Replies Latest reply on Dec 1, 2014 4:15 AM by erolst

    FM 13 - Dropdown multiple choices..

    synergy46

      Here is the popup menu table:

       

      COLOR TEXTURE SHAPE

      red rough round

      red smooth round

      red rough square

      blue rough square

      etc...

       

      The table has a ::COLOR popup and it works.

       

      I can probably create a calculated popup field that holds the 3 choices. ie," red rough round"

       

      The problem is that I want three separate fields on the table (::Color, ::Texture, ::Shape) to get the values selected from the single popup.

       

      But, I can't 'get' how to get the second and third fields to auto-populate after a popup selection is made.

      (Lookups won't work because the need the selected values to be static)

       

      What is the 'trick'???

       

      Thanks

        • 1. Re: FM 13 - Dropdown multiple choices..
          keywords

          Aren't you making it more complicated than it needs to be? As presented you have XX colours but only 2 textures and 2 shapes—but this translates into 4 possible combinations for each colour, so a calculated list could get quite long, and then you'd have to parse the selection back to the original fields somehow. To miy mind it would seem easier to simply present three choices: colour (which could be a drop down list if there are lots or if the list keeps growing), texture and shape, each of which could be radio buttons making selection obvious and very quick.

          • 2. Re: FM 13 - Dropdown multiple choices..
            synergy46

            Right you are.

            I know I can make conditional dropdown lists.  But, it occured to me to inquire if I could get the 2nd and 3rd fields to auto populate given the selection from the first.

             

            I couldn't see a way to easily do it and was wondering if anyone else had run across a tecnique. 

             

            Thanks for replying.

            • 3. Re: FM 13 - Dropdown multiple choices..
              erolst

              synergy46 wrote:

              What is the 'trick'???

               

              Your lookup tables should (like every table) have an ID; use that to define your value list. See attached file.

               

              Having posted that: keywords is right; this list becomes quite long pretty quickly, and then it's more work “parsing” it visually to find the desired entry.

               

              If you store each possible combination anyway, then a separate value list on each field should be faster to work with – and you wouldn't need that lookup table.

               

              Of course, if you want to constrain the possible combinations, then you do; but you may want to think about different selection methods.