Want the impossible?

[GeraldV]

I would like to be able to provide an interface for users to be able to select multiple items from a value list and have it create a new record per item selected. Check boxes or radio buttons would look the best. I know this could be done with a multi-value field, but I would prefer to have one item per record. The image is what I am trying to achieve. Is this the impossible? Any advice would be greatly appreciated.

[IdealData]

You will need to script this.

The method is not difficult, but the script will likely be quite long as you will have around 50 tests to perform - one for each possible option in your check box set.

Once you have established the method for one of the selections then merely repeat for all others.

[comment]

What tests?

[GeraldV]

So I would have to have a test for each of the currently 422 items that the user could select?

[mr_vodka]

Use a global field to capture what selections they have made. Then use a script to loop through each selection in the list and create each record.

You can make use of the GetValue () function in the loop.

[GeraldV]

Ok, I think I understand...maybe I should point out that it took me a week to figure out that comment's DwindlingValueList example had a script attached...I can figure out how to display the data in the format, but I think I am confusing myself about how to actually go about doing that. Here's what I have so far.

I can display the items already in there, but then can't modify the list, and I can display the list and modify it, but it doesn't show what's already in there. I know that's probably a bad relationship on my part.

Can anyone point me to an example of the looping/GetValue/Add record script? This is only my second week of trying to learn in my few spare moments.

MultiValueSelects.fp7.zip

Edited December 7, 2008 by Guest

[comment]

Selecting from a checkbox AND creating matching records in a join table is rather problematic.

It would be quite easy the first time: create a new person, select their stuff in a global checkbox, run a script to take the selected values and create a joining record for each.

But what about editing? You would have to load the existing joins into the checkbox, edit them there, and then synchronize the join table back to the edited checkbox (create new joins for stuff added, and delete existing joins for stuff that has been unchecked). This would be a clumsy and complex process - not to mention vulnerable to multi-user conflicts.

I'd suggest you rethink the interface approach. There are other methods to present a "clickable" joining mechanism to the user, see for example:

http://fmforums.com/forum/showpost.php?post/300477/

[GeraldV]

Thank you for that suggestion. That is much better than what I was envisioning. Plus, I won't have to deal with trying to display a list of 422 checkboxes on the screen, they barely fit even at 6pt. Again a big THANKS

[Oldsneekers]

How about using a portal with your list there, instead of a long list in single field.

For example: Create a table "Stuff" with fields "Things" & "Check". You will have to create a record and populate the fields in the Stuff table first, one record for each of the options in your value list.

OptionA

CheckField is buttonized to put an "X" in the checkField then create the record from the data in this record.

OptionB

2 separate scrips:

1: enters the "x" in the check box (bottonized to the CheckField).

2: "Enter" button that the user clicks after all desired selections are made, buttonized to a script that loops through the portal rows, and if there is a check box makes a record from that data, in the table you desire.

If there are multiple users the "check" could be linked to a user or date or TimeStamp then when done, the checks could be cleared for the next use.

Also the portal could be filtered/constrained (using eg: alpha field-Things field exploded,or category field added to the Stuff table), to trip down the list.

Edited December 9, 2008 by Guest

[GeraldV]

Ok, this is what I decided would work for me. A combo of comment's PortalToPortal and DwindlingVL techniques. This will allow the users to see what has already been selected, delete unwanted items, add new items, and avoid duplicates. Only problem I am having with this now is: I cannot make the delete box go away when there are no items in the portal. It's gotta be something silly that I missed somewhere, but even when recreating the file from scratch, I manage to duplicate the problem.

MultiValueSelects.fp7.zip

[Fenton]

It's a well know problem. Because the [x] Allow creation of related records shows layout objects, like delete buttons (and good ones like drop-down arrows) in the blank "ready for new record data" row of the portal. So, two fixes. If you are only adding things via script, turn off creation of related records in the portal's relationship.

If you are adding rows and need that relational option, then you can create a Container field, and put the button in there. There are best practices for this. But I won't go into that now, unless you need it. I don't think you do, as I don't think you need to allow creation in that portal; just uncheck that option.

[comment]

A combo of comment's PortalToPortal and DwindlingVL techniques.

Oh, no - I now see I have pointed you to the wrong file. Sorry about that. The original PortalToPortal demo, with "dwindling", can be found here:

http://fmforums.com/forum/showpost.php?post/233897/