Deleting Portal Rows when multiple Portals are present

[NasaState58]

I have a layout that is used to select records to put in a match table (attendance) that links two other tables (students and courses). It accomplishes this very well using two portals. One on the left that shows all students, and one on the right that show the related (attending) students only for a given course. In between the portals are buttons with scripts that allow you to directly add or remove records from the right portal by selecting a name from the left to add, or selecting a name from the right to delete.

While this setup works fine with a perfect user, if someone clicks on the portal on the "all students" list and then clicks on the button to remove (which contains the script step 'delete portal row') then that student record is deleted. Similarly, if one clicks on the right "attending students" portal and then clicks my 'add' button, the script (which uses 'get current portal row' to determine the attendance relationship to add) adds the corresponding row number from the left portal to the right portal, though this record is rarely the same person.

What I need is a way to distinguish which portal I have selected. That away I could perform a check in the script to discourage mistakes.

I thought that since the portals use different starting tables that I could use the 'Get(ActiveFieldTableName)' or a similar get function to distinguish between portals, but this seems to be unresponsive to which portal is selected.

Any input is appreciated!

Edited December 18, 2006 by Guest

[IdealData]

Use a Go to field instruction.

As the fields in the two portals are different then you can control which portal is being addressed.

Incidentally FMP 8.5 allows you to name objects on layouts - in this instance the portals, and they can be addressed by their names.

[NasaState58]

Yes, this may allow my script to choose which portal is affected by an action such as 'delete portal row', but I need to be able to prevent any such action from occuring in the first place if the wrong portal is selected... i.e. not perform any record delete at all.

Using the method suggested I could force the script to affect the right portal, but if the wrong portal is selected to begin with, this leads to ambiguities such as which portal row will be affected when I "Goto Field" in the correct portal. Most likely the first record will be selected by default and thus will be deleted, though this definitely would not be the intention of the user.

I need to somehow be able to instead monitor which portal is selected. Thus I can base my actions on which portal is selected and not visa versa.

If I am somehow missing a way this can be accomplished with "Goto Field", please elaberate.

Edited January 8, 2007 by Guest

[TimmyT]

I am having a similar problem. I tried the goto field and it does go to the first portal record as you said, NASA. I also tried 'get(ActiveFieldContents)' 'get(ActiveFieldName)' and 'get(ActiveFieldTableName)'; but all are totally unresponsive to portal rows/fields.

[color:red]Does anyone know a way to make a scipt action depend on which portal (of two in a layout) is selected/highlighted using FMP 7?

[NasaState58]

[color:green]GOOD NEWS!!!

I think I've got it, Timmy. The 'GotoRelatedRecord' function does depend on which portal is selected. At first I created a lengthy script using 'GotoRelatedRecord' that involved deleteing the record from another layout while freezing the current window.

In retrospect, however, I believe the originally desired "test" to see which portal is selected can be accomplished by running a 'Get' function after the 'GotoRelatedRecord'. The 'Get' functions should be more responsive to a normal layout. Then simply perform a test involving a get function, and afterwards return to the original layout to continue the script.

Let me know if this last solution works!

[TimmyT]

:worship:

FINALLY!!!

Great idea Nasa!!! It works great! I've been posting this question on forums accross the web and your the first one with a viable solution. I was just about ready to shell out the dough to upgrade to FMP 8. Thanks again.