Portal lines in scripting

[Wickerman]

Hi -- I'm a little new at scripting.....

I've got a portal set up on a Film Title table giving access to a list of Actors, filtered alphabetically based on a global field the user types in to narrow the range of names. I want to put a button in the portal which, when clicked, will run a script that creates a new record in a Join Field that represents an actor's appearance in the current Film.

So, I've designed a script that grabs the ID key of the current Film record, goes to the Join Field layout, makes a new record, enters the Film ID and then returns to the Film layout to get the ID key for the actor in the portal line whose button was clicked by the user.

My Q: I'm not quite clear on how to get back to that portal line, or rather, the related record in the Actor table whose IDkey I need. What I've done is to put the IDkey field in the portal so it can be grabbed there (I've hidden it behind the name field so the user won't see it) -- but the options in Scriptmaker for 'Go to Portal Row' (first, last, next, previous) don't seem to help.

How do I get the script t retrieve the IDkey from the portal row that was just clicked by the user?

I'm sure this is pretty basic - is my approach to this task sound?

thanks

Albert

[Wickerman]

Ack -- browsing this board, I just discovered what I had already known, that copy/paste isn't a good practice within FMP applications.

. . . so I think my question remains, but a little differently: how do I enter the calculation in the 'Set Field' script step so that it sets the Actor IDkey from the appropriate portal row into the join field record?

albert

[Søren Dyhr]

Several things needs to be done when the use clicks a line in the portal, the ID you wish to use could be stored in a $variable, but you need to store which portal row from where the command was issued, I do usually store it in the scriptparamter via this calc'function.

Get(CurrentPortalRow)

This means that the script terminates by a:

Go To Original Layout

Go to portal row[Get(ScriptParamter)]

BTW isn't it imposible to use copy/paste, but it's a bad habit, because it wipes out what the user might have stached away in the pasteboard.

--sd

[comment]

I believe you're making this more complicated than it needs to be.

Start your script by setting two variables: the ActorID and the FilmID. Then go to the join table, create a new record, and set the two foreign keys to the two variables respectively. There's no need to run back and forth.

Make sure you're grabbing the ActorID from the correct TO, i.e the same TO as defined for the portal where the button is.

[Wickerman]

Thanks for both replies! I've looked up the help topic on 'Set Variable', and 'get(scriptparameter)' which are both new to me. The first I think I understand, while the second baffles me. ("When this function is part of a calculation evaluated within a script, returns the script parameter passed into the script." Huh?)

So . . . If I begin the script with something like

SetVariable [$FilmID; Value:MainTable::#Serial_k]

... I run into the same question about setting a second variable with the Actor IDkey?

... and I'm not seeing how to " set the two foreign keys to the two variables respectively. " -- do I use the 'Set Field' command? I'm not seeing where I find the $Variable options in the calculation box....

I think this is one of those many cases where "It's easy if you know how" -- and I find scripting one of the most impenetrable and poorly documented aspects of FMP. :

Albert

[aholtzapfel]

SetField[yourfield;$YourVariable]

You just type the variable name into the calculation box. (make sure it is exact they are case sensitive)

The 'get(scriptparameter)' is passed to a script either through a button (look at the bottom of the define button dialog box, that is the value passed) or as a parameter in a 'Preform Script' script step.

[comment]

You need to use the Set Variable[] step twice in order to define two separate variables. Roughly, your script would look something like:

Set Variable [ $actorID ; AllActors::ActorID ]

Set Variable [ $filmID ; Films::FilmID ]

Go to Layout [ Roles ]

New Record/Request

Set Field [ Roles::ActorID ; $actorID ]

Set Field [ Roles::FilmID ; $filmID ]

Commit Record

Go to Layout [ original layout]

Script parameters were available before variables. A script can have only a single parameter, and much of the help on Get(ScriptParameter) is dedicated to circumventing this limitation. Fortunately, now that we have variables, this is rarely required.

[Wickerman]

Thank you Mr. -- er -- Tunnel (and all other respondents)

That sounds great, and the comments about the transition from parameters is also much appreciated.

The lingering qestion which I would Love to nail down in my underatanding is how

Set Field [ Roles::ActorID ; $actorID ]

...would "know" to draw upon the Actor ID represented by the Portal Row the user clicks. It just feels to me as though FM would look at that script line and go "WHAT actor?"

I can take this as a matter of faith (once I try it and it works) -- but I'm trying to grasp the underlying dynamic for future use. When a user clicks on a portal row, does FIlemaker somehow privilege that record, such that any immediate scripting action will know to reference that record? I can see that making sense -- is that it?

Albert

[comment]

The step you quote does NOT "draw upon the Actor ID represented by the Portal Row the user clicks." By the time it is called, you are no longer in any portal - you are now in a new record in the Roles (join) table, and you are setting a local FIELD to a previously defined variable.

If you meant to ask how does the step

Set Variable [ $actorID ; AllActors::ActorID ]

know to grab the ActorID value from the current portal row, the answer is that a reference to a related field takes the value from the related record in the current portal row. If the focus is not in the portal, it will take the value from the first related record (you can try this by placing the button outside the portal).

[Wickerman]

Excellent - that's exactly what I was wanting to clarify, so thanks for putting it so clearly. The script is up and running fine, and the lessons learned are going to help not just for this instance but for many to come.

Thanks 1,000,000.

Albert