There are two possible approaches that I can think of:
1) Present the records from your first portal without a portal. Use a list view layout to list the individual records as a found set with data from the parent record displayed in the header. Then the second portal is not a problem as you can add that portal to the layout body.
2) Set up what is called a "master-slave" or "Master-Detail" pair of portals. When you click a button in the row of Portal 1 (Master), a script updates a value in a match field such that portal 2 (Slave/Detail) then displays records linked to the portal record whose button was clicked.
Here's how to set up option 2:
Before you start making changes, you would likely have these relationships:
Parents::__pkParentID = Children::_fkParentID
Children::__pkChildID = Grandchildren::_fkChildID
See the first post of this link if my notation is unfamiliar: Common Forum Relationship and Field Notations Explained
Your layouts would be based on Parents and your Master portal would refer to Children. The trick is to get a portal to Grandchildren that displays the correct set of portal records when a button is clicked in the Master portal...
to do that, we need a new relationship to a different occurrence of the Grandchldren table:
Add a field to Parents, SelectedChild.
In the relationships graph, select GrandChildren and use the duplicate button (2 green plus signs) to make a new occurrence of this table. Double click it ot open a dialog box where you can rename it from GrandChildren 2 to SelectedGrandChildren.
Create this relationship:
Parents::SelectedChild = SelectedGrandChildren::_fkChildID
Put a second portal on your layout that refers to SelectedGrandChildren. This will be the "detail" or "slave" portal.
Add a button to your Master portal row. If you want, you can select all the fields in the portal row and use button set up to turn them into the button to use for this purpose, this enables simply clicking the portal row to pull up the selected GrandChildren records, but precludes being able to edit the fields in this portal.
Either way, set up the button to perform this script:
Set Field [Parents::SelectedChild ; Children::__pkChildID ]
And now clicking the button will bring up the grand children for that child record in the detail portal.
A nice added touch is to use conditional formatting to change the appearance of the selected Master portal row.
Children::__pkChildID = Parents::SelectedChild
can serve as the conditional format expression for each object in the portal row that you want to conditionally format.
Note for users new to scripting:
When Setting up Set Field, there are two Specify buttons that must be clicked. To get Set Field [Table::Field ; Expression], add set field to your script and click the first button (specify target field). Select Table::Field from the list of fields. Do not click the specify button next to the repetition box. Click OK to close this dialog box. Now click the lower specify button (calculated result) and create the expression to the right of the semicolon (;). Do not try to type in the semicolon.
I had to add ?dl=1 to the end of the URL before I could download the file. Drop Box was treating the file as an image file to be displayed.
I've had the same problem and had researched this problem previously on Drop Box's support site so I knew how to fix it and get the file.
Your file has several issues. The most basic is that the fields in the right hand order refer to the Order_content table occurrence instead of the Nav Order content table occurrence. that's why you saw the same data repeated in the portal. You also had an extra occurrence of company that is not needed. You can simplify your set up by linking the Company table occurrence directly to Nav Order Content.
Finally, one of the Order Content fields did not have an Article ID value, the field was blank and thus this record did not link to a record in the Article table.
I would suggest that you either remove Article Name from the Order content table and replace it with a reference to the article name field in Article or set the field to do a looked up value of article name. A looked up value setting won't update if you later alter the article name field in the Article table--that may or may not be what you want. If you refer directly to the article name field in article, you'll always see the current name for that article. And that too may or may not be the best option, you'll have to decide which to use in light of what best fits how you (or your client) does business.
IF you use a reference to the Article::ArticleName field, you'll need to add another occurrence of Article to link it to the Nav Order Content table occurrence in order to show the article name in your portal.
Here's a link to a copy that I've modified as described in this post.
Now I can help you with something! ;)
If you have Safari, you can alt-click a link you force it to download, no matter if its a file that shows up wrong as this one or an image, html page. You may also drag the link to the download manager button.
I'll read the rest of the message now.
Ah, of course, the field reference inside the portal! Makes so much sense of course. Thanks!
The reason for having an unneccsary occurance of the company table is because in my real database its so much lines everywhere in the relation diagram I wanted to clean up a bit. :) Looked kind of stupid when it was there all alone. :)
Your suggestion is good. I haven't looked in to it yet since I couldn't get the first feature to work. I want to have smarter search for adding articles overall, where you can add by article id, name, descriptions, groups, price etc. But that is next thing. Right now I'm happy to get this feature to work, thank you so much!
(in my real usage there isn't orders, that was just a way to illustrate what I wanted)
Thanks for your explanation ( from a few years ago ), it works perfectly. However the user risks inputing data in a portal line that is not highlighted, i.e. not the same line where the button was last pressed.
I tried to attach the the script Set Field [Parents::SelectedChild ; Children::__pkChildID ] to an OnObjectEnter script trigger. I cannot figure out why this does not work, it is like the script does not release control, one is not able to input characters into the portal field after the execution of the script.
It behaves as if the script cancelled the OnObjectEnterEvent. I do not understand why. I read that the OnObjectEnter trigger is a post-event trigger and as such is supposed not to be able to cancel that event.
I tried to work around the problem by extending the script with a ShowCustomDialog step, but the record that is modified by the user input is not the one that is highlighted, its is always the first record of the portal.
I'm afraid that I can't understand what you are describing as a problem.
However the user risks inputing data in a portal line that is not highlighted, i.e. not the same line where the button was last pressed.
Are you referring to the "detail" portal? I can't quite see how that is possible as the detail portal should only show records that correspond with the selected row in the Master Portal.
I tried to attach the the script Set Field [Parents::SelectedChild ; Children::__pkChildID ] to an OnObjectEnter script trigger.
That also does not make sense as what I describe uses clicking on a button and this does not trip any onobjectEnter triggers except possibly on the portal itself. Is that what you tried? And why did you think this was necessary.
A new wrinkle on this basic method now possible with the newer versions releases since this thread was created is to put the "detail portal" inside a popover and position the popover button to be very close or behind the top right hand corner of the "master" portal. A button in the portal row does all that it did previously, but then uses go to object to open the popover. This creates the illusion of having a portal inside a portal to some degree. (To use go to object to open a popover, you need to give the popover panel, not the button, an object name.)
What I am trying to say is that, once you select a ( master) portal row with the button, it is possible for the user to edit a field in an other row. If the user forgets to press the button of the row he wants to edit, he might not realise that the rows in the détail portal are not the row he thinks. ( even with the highlighting like you suggested to implement )
So I wanted to dispose of the button as you then wrote :
If you want, you can select all the fields in the portal row and use button set up to turn them into the button to use for this purpose, this enables simply clicking the portal row to pull up the selected GrandChildren records, but precludes being able to edit the fields in this portal.
I thought that if instead of turning the fields into buttons I attach the script to a OnObjectEnter script trigger I would get the same effet but also be able to edit the fields. But I do not understand why it does not work. Why does the script attached to OnObjectEnter seem to cancel the OnObjectEnter event.
If I attach the script to the OnObjectExit script trigger it works but it is less nice as the user might already have made his mistake.
"What I am trying to say is that, once you select a ( master) portal row with the button, it is possible for the user to edit a field in an other row. If the user forgets to press the button of the row he wants to edit, he might not realise that the rows in the détail portal are not the row he thinks."
No, that's not possible.
The portal (at least as originally designed) ONLY shows the items associated with the selected order.
It is impossible to enter or edit items from another order.
You seem to have implemented some OTHER design; which, unsurprisingly, performs differently.
We have confusion over whether you are describing editing a record in the Master or the Detail portal row. As I now understand it, the concern is over being able to edit fields in the Master portal and not seeing the corresponding Detail records in the Detail portal for the master record being edited because the user has not clicked the button to update the Detail portal.
OnObjectEnter, set up on any of the editable fields in the Master portal should be able to run the same script and correctly cause the Detail portal to update to show the corresponding Detail records. I would expect OnObjectEnter to work the same if set up on the portal row--but haven't tested that option. In your script step, this should work provided that the Master portal is a portal to a Table Occurrence named Children.
That is exactly it, being able to edit fields din the Master portal and not seeing the corresponding Details records in the detail portal.
The thing is, that attaching the script ( SetField( GrandFather::SelectedFather, Father:: ID_Father )) to the OnObjectEnter event does seem to cancel that event, so it is not possible to get into the field to edit it.
Does that script have an exit script [false] step in it?
Or any other steps beyond that set field step? Set field should have no effect whatsoever on what object in the layout gets the focus.
Just to be thorough, I created a simple test file and tested it using OnObjectEnter to set the global match field used in this method. I tried it with OnObjectEnter set up on the text field in the portal row and also by setting the OnObjectEnter trigger on the portal. Both worked as expected, the detail portal updated correctly to show the desired set of related records and the cursor appeared in the field that I clicked in the Master portal so that I could edit the data.
I suspect that your script has a commit records step as that would remove the focus from a particular field on your layout such as the field clicked in your portal row.