Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 1037 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

I created a popover and set 12 buttons in it.  Once a button is selected in the popover layout I set $$var to the button value via a script.  I verify this using the tool function.  I then use the script trigger on that button to perform another script that will use the $$var value.  The thing I want to happen is when I click on any button in the popover layout, the system will gather the data and then close the overall popover.

And then perform a script, maybe.

 

Any thoughts?

 

Thank you in advance.

Posted

I would suggest a different approach: use a single script and make the buttons pass a specific value to the script using a script parameter, instead of a global variable. Then start the script by closing the popover (using the Close Popover script step) and continue to perform the action using the value in the script parameter.

Keep in mind that any global variables you create (and do not actively erase) will "live" until the end of the session, hogging memory and possibly conflicting with further actions using the same variable name.

 

Posted

If I'm not mistaken I have already considered your proposed solution (if I understand it correctly) but this forces me to make twelve different scripts (one for each month button).  This seems kinda messy and doesn't flow well.  I was hoping to use a script trigger in all of my twelve buttons to invoke the close popover function but this does not seem to work.  For example,  I want to click on the "JAN" button and setvariable  $$var1 = "JAN" (or "FEB, or "MAR", etc.) and then when I release the mouse button I set script trigger on the individual buttons to "onobjectexit" = perform script "close popover" and move on to a different script.  It seems that the only time that "onobjectexit" function works is when the main popover button is closed, not when any of the "sub-menu" buttons are acted upon.

Does this make sense?

Any thoughts?

Thanks again.

Posted
14 minutes ago, revjj said:

but this forces me to make twelve different scripts (one for each month button). 

You are very much mistaken. And, if I am following your description correctly, you are grossly overcomplicating something that can (and should) be very simple. You do not need any variables, and you do not need to trigger a button OnObjectExit. All you need to do is define each button to run the same, one and only,  "final" script (i.e. the script that performs the actual action - the action that you did not disclose to us, and requires one of the 12 values) and use the script parameter to pass one of the 12 values to the script. 

 

Posted

I agree.  I was hoping to make a script that would say "GetButtonName" or something like that and then proceed to sort my fields by button name, i.e. "JAN", "FEB", etc.  I could not find a way to get the button name so I opted to set the data with a SetVariable = $$var in each button.  That part works well.  But after that, nothing else functions until I click out of the popover button.  Then, the rest of the scripts run fine and I get my expected results.  So for clairifiction, here goes, this is what I want :

Popover button click reveals 12 buttons listed "JAN" to "DEC" in a vertical fashion.  All buttons would perform the same script.

Click on any month and that button will specify the month and put it in a field or var I'm looking to sort for.

Also, upon clicking the month button, the popover goes away and then the sort function proceeds and gives me the results in a different layout based on the field or var.  i.e.:

     Show all records

     if (field) month (or $$var) = "JAN" (or "FEB", etc) or button name

     Sort range xx/xx/2022.....xx/xx/2022

     Close popover

     Go to layout ABC

Posted

I am afraid I could not understand what your script is supposed to do with the value it gets from the button. You cannot sort records by "JAN", that just makes no sense. Neither does "Sort range xx/xx/2022.....xx/xx/2022". 

Posted

We're getting out in the weeds here.

If the button sets $$var1 to "Jan" or any other month it uses it to filter out that month out to display the data.

image.png.b8512e01f333fb20d9f4a0fac90e470d.png

 

The sort/find function is here

image.png.948476c369a3c5023e1269084f87bbd2.png

Did that clear things up for you?

Posted (edited)

Well, find is one thing and sort is something completely different...

I also see that your script is hard-coded to find records in the year 2022. I wonder how long that's supposed to last.

Anyway, I am attaching a simple demo file that shows what I tried to tell you all along  Each button finds records in the corresponding month of the current year (not hard-coded). Please note these important points:

  • There is only one script.
  • No variables are used.
  • The buttons do not have object names.
  • The button labels are not used in the script.

FindMonth.fmp12

 

--
BTW, I have included the Close Popover script step in the script - but it is in fact not required, because the popover will close automatically when the script enters Find mode.

 

Edited by comment
Posted

I must say that is really amazingly simple.  It appears to do what I want.  I'll have to see if I can apply it to my application.  Thus far, no success.  I need to learn more about ScriptParameters.

Regards and thank you

Posted (edited)
1 hour ago, revjj said:

Thus far, no success.

Attached is an example showing the power of passing value(s) to a script parameter.  Notice the button attached to 'Jan' has a 1 when you attach the script to it.  On the 'Feb' button, you change the script parameter to a 2 and so forth (representing the month number).

Then when the script fires, it takes that 1 (in this case) and uses the value you pass it - the script parameter.   Passing values to a script, based upon layout or record information, is one of the greatest powers in FileMaker so I wanted to be sure you understood its power.

Another example: You want to use the record's serialID and create a child record in another table.  Clicking into the 'optional script parameter' (in a script called Create New Child will open a calculation window where you can simply select the serialID from the left pane and insert it into the calculation as: Table::SerialID.   Then your Create New Child script simply use the script parameter there.

Pass value to script parameter.png

Edited by LaRetta
Posted

I wanted to say thanks to all for the assistance.  It works like a champ.  Who came up with this? Or is this something I missed in Filemaker 101 training?

 

Posted
21 minutes ago, revjj said:

is this something I missed in Filemaker 101 training?

I would say that is the case. The technique of using a script parameter to make the same script do the same thing with a different value goes back a very long time - at least v.7 if not earlier.

Posted

I've studied the help documents that LaRetta provided and I still don't get it.  Now I'm looking for the same approach (using a similar popover) to find a field, sort them and then go to my charts layout.  Can this same script be used for that with minor tweeks or do I have to use a different Let statement or other calculation or even another Get statement, i.e. "GetActiveField".  As I say, I still don't fully get it.

Thanks again.

Posted
5 hours ago, revjj said:

Can this same script be used for that with minor tweeks

Probably, but I cannot tell for sure with such scant description. Maybe start a new thread and explain in detail exactly what you want to do.

Before you do that, consider spending more time on "getting this" because it is an indispensable tool to have in your toolbox. It's actually very simple: each button is defined to have 2 properties:

  1. Which script to rum;
  2. What value to pass to the script; this value is called the script parameter.

The script extracts the value passed to it using the Get(ScriptParameter) function and uses it to modify some of its behavior.

For example, in my file the button labelled "Mar" is defined to pass the value of 3 to the script. The script then uses that to find records in the 3rd month of the current year.

 

Posted

yea, I kinda figured it out.  This is the script I wrote.  Not as clean as what was described earlier in the month find script but it works.  Was hoping to find something a bit more cleaner.

 

image.png.2328a97df362201fc61621b1b0050e4d.png

Posted (edited)

There is absolutely no need to store the script parameter in a variable. The script parameter is a register just like a variable and you gain nothing by this transfer. And, as mentioned earlier, you should not use global variables (prefixed by $$) unless you intend for the variable to persist after the script has run out, until the end of the session. If you do need a variable in your script use a script variable (prefixed by $).

There is no need to show all records before doing a find. And doing so when you are already in Find mode is even more useless.

So your script could probably be reduced to:

Enter Find Mode []
Set Field [ test::BT ; Get(ScriptParameter) ]
Perform Find []
Go to Layout [ ... ]

I say "probably" because you have stored find requests in both your Set Field and Perform Find steps which I cannot see in the screen shot (next time please post a printout). I don't know what they do (or are supposed to do). The only thing I can say is that if you do need to store requests then store them in one place, not two. And IIRC if you store any find requests in the Perform Find step, then those are the only find requests that will be performed.

And I did not understand the purpose of the last Set Field step.

 

Edited by comment
Posted

I tried something similar to what you propose here but it did not seem to pass the data.  I say similar, not exactly.  Regarding storing S#!t in two places, I'm just trying to figure it out.   I'll give your suggestion a go and see how it works.  I was thinking that because I was doing a find or switching to another layout, maybe the data was lost.  not sure, hence the $$Var.  BTW, the last Set Field step was just leftover trash I failed to delete before doing a screen capture.  I don't think it has any effect on what I'm trying to do.  It's deleted now.

FWIW.  Please be advised that I started using FM way back when it was first introduced to the MacPlus, circa `85~`86.  I fell out during V6.  Now I'm back into it after all these years.  My first successful project was for generating lottery number picks.  Chose any amount of random chances and then choose the number of picks you want from the pool.  All 100, 1000, 10,000 etc random picks were unique, no duplicates.  It works really well and incorporates powerball, megamillions and lucky7.  The point is that I now have more time to devote to learning more functional, simpler ways to design things.  FM is the most powerful/flexible tool in the industry.  So much has changed since the 80's.

Thanks again

Posted (edited)
1 hour ago, revjj said:

I was thinking that because I was doing a find or switching to another layout, maybe the data was lost

Both the script parameter and a script variable persist until the script runs out.

 

1 hour ago, revjj said:

the last Set Field step was just leftover trash I failed to delete before doing a screen capture.  I don't think it has any effect on what I'm trying to do.

It does have an effect on your data, because it modifies the first record of the found set. If the variable was "foo" and the value of the first record was also "foo" then the only effect of this is to update the last-modified fields. But if you searched for "foo" and the found record had "footer" then you would have distorted your data.

 

Edited by comment

This topic is 1037 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.