I've been searching an experimenting, but not getting anywhere...

I would like to send an Object Name as a Script Parameter, when a button is clicked (the name of that very button). Ultimately, I need the result in a Variable, "$ButtonResult".

Does anyone know how to accomplish this? I found the "Get(ActiveLayoutObjectName)" function, but it never returns anything...

Thanks!

Michael

The active layout object is the one that is currently selected. Clicking a button does NOT change the current selection. The only way I know of to make a button become the "ActiveLayoutObject" is by tabbing into it (assuming it's included in tab order), or by using the 'Go to Object' script step.

I've been searching an experimenting, but not getting anywhere...

I would like to send an Object Name as a Script Parameter, when a button is clicked (the name of that very button). Ultimately, I need the result in a Variable, "$ButtonResult".

Does anyone know how to accomplish this? I found the "Get(ActiveLayoutObjectName)" function, but it never returns anything...

Thanks!

Michael

What you're trying to do won't work. You need to hard wire the parameter into the button's peform script action.

Comment, Bruce, thank you for your replies.

What I wanted to accomplish is making portal functionality "universal", with the help of object names. I feel that adding an removing records in portals is creating a lot of overhead in my solutions. I have search functionality, tab-memory, sorting in column view - all of which that works with one single script for the entire solution and independently from layouts or tables, and I was hoping to accomplish the same with portals.

Any tips?

The workflow is... the user clicks a "+" button to add, say, individuals to a company. The solution produces a pop window with a list of available individuals. The user can check one ore more individuals, clicks an "add" button, and the individuals are added to the company (and now show up in the portal).

I like the pop-up window, because I can place search functionality etc. and I can lock it, so the user has to complete the process he started - or cancel it properly.

Edited September 15, 200817 yr by Guest

I think I got it - I can pass multiple parameters.

The workflow is... the user clicks a "+" button to add, say, individuals to a company. The solution produces a pop window with a list of available individuals. The user can check one ore more individuals, clicks an "add" button, and the individuals are added to the company (and now show up in the portal).

I don't see how sending the object name as the script parameter would be useful in this scenario.

I don't think I'm good at explaining... sorry.

I thought it would be easier/faster to rename the object name of the buttons on the layouts rather than going into the button's parameter set-up. This way I could have copy-pasted portals to any layout, and have them fully functional by simply changing the object name of the button.

It's ok though, I'm now sending three parameters to the script: origin table, destination table and the function (add/delete). This still allows me to have one script to run the entire portal functionality in the whole database, including join-tables.

This is a portal of buttons? Or a portal of data which inludes a button in the portal? What is the portal based on?

It's a regular portal with related records, and a "add" and "remove" button. I posted an image below.

I just got tired of having a dozen scripts for user friendly portal functionality, and was looking for an universal approach.

PS: And yes... I know FileMaker can create related records automatically - but to me that just isn't flexible enough in regards to interface and workflow choices.