I have a table titled Matters and a second table titled Notes that relate to the individual matters. I have created a portal in Matters that displays an abbreviated version of the notes that looks somewhat like the the individual email list in Mac Mail. I would like to be able to select a individual note in the portal that then displays the complete contents of the note in a "note content" box next to the portal - similar to what happens when you select the individual email. 

 

If you put a field in the "note content" box it displays the content of the most recent related record. I'm thinking that the result I want could be scripted with a button over the portal row that would use the GTRR step, but I wanted input on whether this would be the simplest way to do this.

 

I used to do this by creating separate layouts and using GTTR but I'd like to stay on the same layout if possible.

 

Thanks for any suggestions.

• create a new field, say, selectedNotesID

 

• format an object in the portal row (or create a dedicated button) to initiate a script that sets (or unsets) the primary notesID of the portal row record into the selection field

 

• create a new TO of Notes, say, Notes_selected, and connect it to the Matters table in a new relationship where Matters::selectedNotesID = Notes::primaryID

 

• put the desired fields from Notes_selected on your Matters layout

Works like a charm. Thanks.

Note that this technique is not multiuser safe. All users connected to the system see the same selected note. Changing the selection field to a global field prevents this problem.

You can eliminate the need to add a field or a TO altogether by using a variable to filter a portal - see a demo here:

http://fmforums.com/forum/topic/71867-getting-more-out-of-filtered-portals-2view-selected-child/

BTW, Bruce, I believe that Oliver was referring to a global field for the selectedNotesID but it's good to clarify. :-)

 

In all, particularly with improvements to portal filtering (more efficiently handled by FMS in v13), Comment's link provides great option with less schema-clutter.

 

Portal filtering and value lists both have gained a boost in 13 making them more appealing for various tasks.

The filtered portal approach is a great suggestion. LaRetta, do we know details about improved filtering in 13, is it documented somewhere?

Note that this technique is not multiuser safe. All users connected to the system see the same selected note. Changing the selection field to a global field prevents this problem.

 

We don't even know if there are users plural. Using a global will show a given user the same selection for every record, so you could say it's not multi-record safe … 

Depends in how the relationship is defined. The relationship should include the parent and foreign keys, as is customary for this kind of child selector method.

We don't even know if there are users plural.

 

IMHO, it's good practice to assume multi-user deployment. Even if the assumption proves false at the present, a successful solution has a good chance of becoming multi-user in the future.

 

 

Using a global will show a given user the same selection for every record, so you could say it's not multi-record safe … 

 

That's not an equivalent comparison.  Depending on the circumstances, the user expectation when switching to another parent record can be one of these three:

 

1. Continue displaying the selected record;

2. Display nothing until a new selection is made;

3. Restore the selection previously made for this parent record (if one was made) by this user.

 

Note that #3 can be implemented in a multi-user scenario, even if using a dedicated TO.

 

However, under no circumstances does the user expect to load a parent record and find the selection made for them by another user.

Yes  - this is a multiuser (10 or so) deployment over a local network using FileMaker Server 12. I tested the suggestion on my individual machine and not through the server so I appreciate the additional input.

Tested which solution?

The one suggested by eos on a single machine. I have opened the viewselectedchild file suggested by comment, but I have not been able to adopt it yet. I admit that I don't understand it yet because I have not worked much with variables. My solution was initially built with FMP 3.0.

I understand the fields and the relationships but I don't understand who using a script to set the variable leads to the result that the elected record is displayed. I'm also not sure if I am defining the variable correctly with the fields in my solution. Also the ID fields in the viewselectedchild file numbers and are text in mine so I'm not sure if the that has an effected either. I'm sure that with time and experimentation I will figure it out.

 

Also, when I open the viewselectedchild file in FMP 13 Advanced a number "4" appears on the left side of the field in the portal both in browse and layout mode. Didn't show up in FMP 11 so I'm confused by that too. Ah, I love a challenge that leads to knowledge.

Yep. Got the viewselectedchild process figured out. I knew that I was missing something, and it turned out to be that the "field" used to display the selected record was actually two fields within single row portal that had portal filtering active using the variable in the calculation. Then the "set variable" script made sense and everything worked. 

 

I'm going to try both suggested solutions over my local network.

 

Thanks again for the guidance.