Repopulate Portal when another field changes

[Bill C.]

I'd like to have a layout where selecting an element in a popup list causes a portal to repopulate. I'd have no problem with this in an event driven UI, but FMP's layouts aren't event driven. So, how does one do this sort of thing. Here are the details for my schema so we can talk about specifics.

I have a many-to-many relationship between Contact and Group tables via a Contact_Group table. In the Contact layout I'd like for the user to be able to select one Group from among all Groups associated with that Contact. Based on that selection, I'd like to update a portal on that layout such that it lists all (other) Contacts that are in the selected Group. So in summary, the user selects a group and gets a list of all other contacts in that group.

The first problem I have is how to make the initial selection of a Group cause a script to run. Perhaps I haven't done it right, but I can't seem to define a popup as a button so that the *selection* causes the button to "fire". So far I have to do the selection, then click the selection, but that seems pretty ugly.

I'm assuming if I can solve this first problem that I can figure out how to repopulate the portal; although I certainly wouldn't object to any pointers or hints for that step too!

Thanks in advance.

Edited August 30, 2005 by Guest

[sbg2]

Please post a mock-up file so we can SEE the way your file is setup. Do I understand correctly that a contact may belong to more than one group?

[Bill C.]

I'll post a file. Yes, a contact may be a member of more than one group (and of course a group may have multiple contacts in it.)

[Bill C.]

Please post a mock-up file so we can SEE the way your file is setup.

Here's a trimmed version of the database. I think I've actually got it figured out using a global and a value list based on a relation as the validation rule. It all seems a bit roundabout, but I'm beginning to see that FMP requires a different mindset than I'm used to. I'm used to event driven architectures, whereas FMP seems to be more declarative. I still have a queasy feeling that I'm going to hit something that "you just can't do" in FMP, but thus far I've managed to find solutions -- thanks to these forums!

Anyway, take a look at the Contact layout and the CurrentSelectedGroupID field in particular. Let me know if you see a better way.

My current problem, BTW, is how to reinitialize the global whenever I open a new Contact record in the layout. My guess is that I'll have to do that in script and also require use of a button to actually transition to the layout (or a next/previous record within the layout.)

Another problem is how to display the Group *name* in the CurrentSelectedGroupID field, but actually store the ID into the global so the relationship works. Any ideas?

Spike.zip

Edited August 30, 2005 by Guest
forgot to attach file!

[sbg2]

See if the attached helps you out any, Its a stripped down file similar to the one you provided. From the file you provided I'm not quite sure how you are defining what groups a contact belongs to?

Contact.zip

[Fenton]

This is a slightly different technique. In either case you need another table occurrence of the Groups table off of the SelectedGroup, in order to view the group name.

I noticed that yours did have a mechanism to add a group to a person. The easiest way to do that is to turn on "Allow creation of related records", then use a portal to show their groups. This is essentially the same as what your filtered value list was showing in its drop-down menu. Since there are likely few groups per contact a portal seems fine.

Since the group name is visible but not enterable in that portal, why not make the group name a button to toggle display of the members of the group in a portal below, with the selected group in a Merge field above.

The button (attached to the field itself) is running a script. It could just be a single step with no script. But the Commit Records afterwards makes everything look and work better.

I also changed the SelectedGroup field back to a regular field. It really is not a global choice; it's more tied to the record. It's only a small number, so it takes up little room in the database. That solves the problem of having to clear the field via script every time you change records.

Spike_fej.zip

Edited August 30, 2005 by Guest