You already have that field...the field you populated via checkbox. While it LOOKS like a set of checked boxes, the field is actually a return delimited list of the checked values.
Put the field on your layout again, but don't set it up as a checkbox...just an edit box. Make it tall on your layout and you'll see the return delimited list.
Now the question is what you're trying to do with it... (?)
The problem is the list is made up of single records. One checkbox per song.
There are a number of ways to do what you want, with the right relationship, the list function could return this list for you easily, but Ninja has asked the key question: What do you want to do with this field once you have it?
It's possible that there's a better way.
If you wish to display your list of songs in one line as comma separated, you can easily do that. Prior to vs. 11, you can create calculation to display as: Substitute (yourCheckBoxField ; ¶ ; ", " )
If you have version 11 then you don't need to waste a calculation - you can place it directly on the layout as a layout-level variable. Here's how:
Create a script called Freeze Window and the only step is Freeze Window. Type the following on your layout <<$$songs>>
Attach a script to your Checkbox field "OnObjectModify" and select your Freeze Window script. As the script parameter, declare your variable as: Let ( $$songs = Substitute ( yourTable::yourCheckBoxField ; ¶ ; ", " ) ; "" )
As you check and uncheck the songs field, it will change the display (ON THAT LAYOUT).
So as Ninja asks, what do you want to do with that new field? If for export as single line then you'll need calculation.
BTW, many times, conditional format can trigger layout-level variable change (if you declare the variable FIRST on the layout in back of stacking order and in the header) but with data change, it must be trigger to Refresh as I've indicated.
Using script called Refresh Window and then using variables in Let() was picked up from Mr. Vodka and is very powerful. Technique of changing layout-level variables (display of any values including calculations without calculation fields) was picked up from Mr. Vodka and Comment.
And that's what happens when I'm pulled away to handle something else and don't see the following posts, LOL!
If you have multiple FIELDS for your songs then I suggest you reconsider your structure. Multiple ''like' items should be records instead of fields. :^)
"Ninja asks, what do you want to do with that new field? "
The purpose of the database is to quickly generate a song set list for a performing artist. So there will really be 4 sets all together. I did one using a report but the sets need to be 4 up on a page. Hope that helps.
Sounds like something for which you might use a portal. You could then have 4 such portals and the relationship for each portal could either include the check box field as part of the relationship or in filemaker 11, you might have one relationship for all 4 portals with a different filter expression for each.
No, it doesn't really help. We have no idea how you are structured. What do you mean by '4 sets'? Sets of what? Does a song contain many details (fields) which should appear on the layout with the four songs selected? What version of FM are you using? What do you want to do with this list? Do you want to select four songs and then perform a find in a 'songs' table and view their details? Do you want to print a list?
What is the context and purpose?
LaRetta, sorry for the confusion. First the specs: Using FMP adv 11, The purpose of the database is to help a band of musicians come up with live music "sets". Usually 3 or 4 sets are performed at an event and there are roughly 10 to 15 songs in a set. The selections come from a master list of say 500 songs (records). Depending on the venue ie Bar, Wedding, Concert and style of music ie Dance, Listening, they can check a box next to an appropriate song to be performed.
Although the database contains other details of the song ie tempo, Who starts it, music chart, genre etc., the bottom line here is to generate a printed "set" list to pass out to each player. Only the song title is needed. A simple report would work BUT it was requested to print 4 up on a page. I was thinking, use a blank layout and place the text blocks 4 up as you might using a page layout program. So how do I create a field or return delimited list that collects the data (song title) based on whether the checkbox is checked?
It would help to see your file so I know how you are structured. You would want to track what songs were played at a specific event, right? The next time that person has a birthday party, they may wish to use the same songs in that set order (or at least review that list). And it would help you to know that, when eventing a wedding, you had several songs which were rated by the host or guests as great so you could fine-tune your suggested lists next time. Order of the songs would also matter ... you wouldn't want Olde Lang Syne to be in the first set at a New Year's Eve party!
Without understanding your structure, it is difficult for me to offer specific advice. I envision a join table where you would tie a song to an event and include the set number you specify. Then producing a one-page summary of the four sets for the event you specify would be simple as placing 4 portals on your Event layout. Songs can even be added directly from your event layout.
How would the musicians select the songs? Even if from the Songs table, they can specify the event it is for (you can use global to hold the event once during the session. They would select the song and specify the set. Can you upload an empty clone of your file and provide a link here? Otherwise it would help to at least see a picture of your graph on how you are structure. File is always easiest for a good response.