You may want to put the Notes in their own table related to the table used in your current portals. That would allow recoring multiple notes for the same portal row in a better organized fashion.
Whether or not that suggestion works for you, you can use "master-detail" portals synched via scripts and conditional formatting. The scripts keep the records in the "detail" portal in synch with the "master" portal via a button in the master portal's row that you click to select that record. The conditional formatting then changes the fill color of the fields in that master portal's row to show that this is the current record for which you see one or more notes records in the other portal. (And if you only have one Note for any given record in your master portal, you won't need a second portal, you can put the notes field directly on the layout.)
See this thread for more on "master-detail" portals: Need layout solution for nested portals...
Yes, I already have a master-slave portal system and the 2 slaves call up the correct records when the master button is activated. My concern is that when I'm working on Portal slave a. record 4, it not obvious which is record 4 in portal slave b. What would be nice is that they scroll in synch and when I click into portal a. record 4, record 4 in portal b. automatically conditionally formats (as well as scrolls to the same position).
Is this possible?
Would a script involving: 'Go to portal row' help? How do you numerically identify a portal row? And can you from this information synch portal rows from the same table but in different portals from knowing the portal row??
Something is missing here.
With a master slave pair of portals, if you are woring on row 4 in the master portal, the ONLY records visible in the slave portal are those linked to that portal row record, there should not be any other records visible in that portal. And conditional formatting can "highlight" the fields in portal row 4 to show that this is the current "master" record.
Yes, that bit is fine. However, once there are several rows in the 2 slave portals (eg. a. and b.) it isn't obvious which belongs to which. Eg. If there were 8 slave records related to the master but only 4 records show in the slave portals a. and b it could be that a. shows 2-5 and b. shows 5-8. How can you conditionally format say record 4 in both the slave portals + preferably have them scrolled to the same level so that it's obvious which is the same record?
TWO slave portals?!!
I could easily be wrong here, but it sounds like you have this: LayoutTable----<Master----<Slave1------<Slave2
Where you click a portal row in Master to bring up a set of records in Slave1, then click a portal row in Slave1 to bring up a set of records in Slave2. If so, this is simply the master slave technique set up twice over.
To control what records appear in Slave2 can be done either with a portal filter or a relationship from LayoutTable to a Table Occurrence of Slave2, with the portal to slave2 based on this new table occurrence. (These are the same methods you use to control what records appear in Slave1.)
I've got tables related: 1<2<3.
On the layout for T1 I have:
- A T2 master portal, with a select button to call up the T3 slave.
- 2 T3 slave portals.
The attachment shows the T2 master (top) with 1 record selected and the T3 slave portals (middle and bottom) having called up their related records. That bit works. However, once I get quite a few records in the slave portals and a say, scroll to the 4th record in portal T3a, I won't know which is record 4 in portal T3b (bottom) unless I put an ID field in both. However, that still lacks the convenience of having the T3b record being 'highlighted' the second I start to edit the same record in T3b. And having them scroll in unison to the same position would be neat for users too.
I reckon I"m asking too much of FM?
There isn't any way that I know of that will perfectly scroll the two portals to T3 in unison. Best approach I can think of is to remove the scroll bar and use either a relationship or a portal filter to "page" through the related records in T3 one fixed size group of related records at a time. That, in turn, could be synched as both T3 portals can then be updated simultaneously to display the next set of related records.
It sounds like it would be better me splitting the table that is source portal T3a and T3b and instead have T3 and T4 related to T2.