You need a portal on your layout which will display all records based on your relationship. Each field in a portal can be setup as a button which would perform a script that goes to related records in the current layout or another layout for edit.
thanks for the sample ... looks really interesting ... works even without a script as I see. I implemented this on my app with the following results:
- the desired results are displayed on the list, please look at the screenshot, blue / white column on the left side
- when I click on an entry I get the error " ... because this layout cannot display the result". I suspect it has to do with focus on the the app.
Please see the screenshots below. Also a quick summary of relevant parts of the app.
The layout's focus is the table Contact which includes all details of a guest. At the same time the list displays records from the table Request. The layout is built on four tabs that display different pieces of information of several related tables. I have tried changing the focus of the Layout to the table Request, but then the other tabs don't work anymore.
In the list that I created I need to display all guest requests for a guest. The results are displayed correctly as mentioned before. Request information is saved in the table Request which contains 0 to n entries per guest. The tables Contact and Request have a relationship Contact::ID = Request::Contact_ID.
In the list with the buttons that contain dates and are designed to jump to a particular record in Request I have used all settings as per your sample app. The display of the contents works, the jump to the selected record doesn't with the above mentioned error. Can you give me a pointer where I should search ?
If you use "Go to Related Records" using the current layout you should not have this message. This may have to do with your attemp to go to the correct tab. To navigate the tabs, you must name each tab from the inspector. In layout mode click the tab and then from the inspector click the position tab then the first field is name. This is where you give the object a name. You can give it any name In this example i will use tab1. Then click the next tab and give it a name of tab2 and repeat for all tabs. Then from your script to go to the tab you would use "Go to Object [tab1]". The tab that has your request.
Your button setup would peform a script, which would go to related records, then go to Object [tab2].
If you still have problems, I would suggest putting up a screenshot of your button script.
A simple list view layout with "go to layout" buttons in the body can also be used for this. See the Known Bugs List for an example of this approach. (Click the find button and enter search criteria that match to multiple records.)
Actually I don't need to navigate to another tab. I put the list as the first in sequence and FP doesn't complain anymore ... albeit it doesn't jump to the record either. I still think it is a combination of focus and
- The list (now first in sequence) is loaded with Inquiry Dates from the table Request with correct values.
- When a user clicks on an element of the list it should first of all go to the corresponding record in Request and refresh all the fields in yellow (they are from the table Request) that are at the right side from the list. Now there is no error message, but the fields on the right side are not refreshed.
The current Button Setup is in the screenshot further below ... I am not using a script.
Any other thoughts ?
@PhilModJunk: I guess your suggested approach would not work, as the user will not be searching for an inquiry date ... but actually needs to pick an existing inquiry date from a list.
I see no reason why it wouldn't. I suggest taking a look at the file I mentioned. It is implemented to help a user narrow the results of a find, but that does not mean that you would have to do so. It lists a set of records in a a list and clicking one changes layouts to display a detailed view of the record clicked by the user.
I see what you are saying. The Known Bugs List filters the records using a script. That is probably the clue. I show the list with the x elements, and once an element is picked up I filter the outstanding records.
it is now sort of (not) working. I have traced with the debugger. The pointer in the Request table (that is the list of dates on the left side) moves to the appropriate record when I click on the list element on the left side ... but it doesn't show the record in the portal. I rather get error 414 "This operation could not be completed because the layout cannot display the result". Any ideas about why this error is ocurring ?
It would help to see the actual script. For some reason your debugger shows the error, but not the script where this error was tripped. Was this a single step button that you cilcked? If so what button action did you specify? if not, please post your script.
To post a script to the forum:
- You can upload a screen shot of your script by using the Upload an Image controls located just below Post A Answer.
- You can print a script to a PDF, open the PDF and then select and copy the script as text from the opened PDF to your clipboard for pasting here.
- If You have FileMaker Advanced, you can generate a database design report and copy the script as text from there.
- If you paste a text form of the script, you can use the Script Pretty box in the Known Bugs List database to paste a version that is single spaced and indented for a more professional and easier to read format. (Use the HTML option on the database tab panel and paste the text into the forum's HTML editor.)
Actually it is not a script. I have done everything with the table relationships. It is just a button with Get Related Record from and Show Record Using <Current Layout>. It is the Inquiry tab of the current layout. I have to say however that the fields are outside of the portal. Here the screenshot with the Button settings.
Unless your current layout is based on an occurrence of the same data source table as Request ID, this won't work and you'll get an error message.Normally, this type of button with this script step should specify a different layout as it is used to bring up the record of the row clicked in a different layout.
I see. Is there any butoon / script step combination that can be used when specifying the same layout ? In the end it is only a matter of moving the pointer in the table.
You'd need to add another relationship from the portal's table occurrence back to an occurrence of the layout's table. This would require adding an additional table occurrence to your relationships graph:
Then you can use GTRR to specify LayoutTO 2 as the "table" parameter in the GTRR step.