Finding Portal Containing Cursor

[Keith Silva]

I have a layout with 5 portals. They are use the same two database files, but they filter the data in different ways. I want a user to click on a portal and then press a button on the layout that is able to detect which portal has the cursor to pass certain data through the button's script to an external script. Everything works, except that I can't detect which portal has the cursor. I'm using the set field script step with the following "Specify Calculation":

Case(

Status(CurrentFieldName) = Colleagues::cPersonOrganization, Colleagues::mPersonID,

Status(CurrentFieldName) = Associates::cPersonOrganization, Associates::mPersonID,

Status(CurrentFieldName) = Stakeholders::cPersonOrganization, Stakeholders::mPersonID,

Status(CurrentFieldName) = Interested Parties::cPersonOrganization, Interested Parties::mPersonID,

Status(CurrentFieldName) = Regulated Party::cPersonOrganization, Regulated Party::mPersonID

)

This case statement does not pass the field information I was expecting, but neither does it generate an error message.

I think I'm either using the incorrect syntax in the case statement, or the Status(CurrentFieldName) function does not work with fields in portals.

I'd appreciate any guidance to fix this problem.

We are finally getting rain in the San Francisco Bay area this weekend, at its a cold rain. Perfect weather for working with FileMaker!

Thanks, Keith Silva

[BobWeaver]

If you place a button right in the portal, a copy of the button will appear on each row. When you click the button, that row will be deemed the current related record in any calculation that uses related records. For example the button in the Colleagues portal could perform this script:

Set Field gblPersonID = Colleagues::mPersonID

Perform Script YourExternalScript

This puts the contents of the portal row into a global field gblPersonID which can be accessed by the external script. Create a similar script for each portal which sets the gblPersonID field to the desired value and calls the external script.

[LiveOak]

I did a test and the function only seems to trap the field name, not the relationship and "::". This would be OK if each portal displayed a different related file. It seem that you a displaying different relationships to the same file, so all the field names (sans relationships) will be the same.

The only thing I can think of is to put a button over each field which sets a global field to a portal identifier and then does a go to field to the field you were clicking on. To make this work, you have to omit all fields from the tab order.

Another status function that is almost useful...

-bd

[Keith Silva]

Thanks Bob and LiveOak. Your responses are very helpful. I was trying to avoid a lot of little buttons on the layout, so I think I'll focus on LiveOak's suggestion. I was also perhaps trying to be too clever by avoiding the use of another global field and/or separate scripts for each portal. I'll report back if I come up with something other than what is discussed in your responses. Thanks again.

Regards, Keith Silva

[BobWeaver]

Hmm, that's strange. Maybe I didn't understand the question.

My own client contact database is set up so that when I pick a client company, a portal displays all of their employees. There's a button overlayed over the whole portal row so that when I click anywhere on a row, it sets a field to that person's ID number and brings up their personal data.

[Keith Silva]

I think you understood the question. I'm trying to do essentially what you have described for your client database except that I want to go to personal data by pushing a normal command button on the layout rather than a button on the portal. I didn't think it was going to be this difficult. To do this, the button script needs to be able to detect which portal contains the cursor. I am trying to avoid showing a small button on every portal line because it looks cluttered, especially with five portals on the layout, and the purpose of the little buttons isn't always obvious. I also want to avoid a hidden button on a portal line because its function isn't always obvious to the user. With a normal command button, the button label indicates its function. The results of LiveOak's tests look promising because I don't need to pass the relationship name to the external script, only the contents of the PersonID field. I'm still working on this, but if I can't get it to work, I know I can use one of the two button-on-a-portal-line techniques. The feedback from you and LiveOak was useful in helping me determine that I wasn't missing something really obvious, which I'm prone to do.

Thanks, Keith Silva