Set Variable [$name, GetValue($names, 1)]
New Record/Request
Set Field [The Name Field; $name]

However if you add $name as an auto entry calc in the target fields define fields options –

For setting a single field a script set is fine sometimes however when I am setting several fields after the New Record each field that gets data past to it during a script will have an auto enter calc with a script variable with a variable named similar to the field.

Declare variables by setting a $someVar to=

Let ( [ $name = Name Field; $uid ; UID Field ] ; "" )

Go to target layout.
Create new record

All fields are filled in, and creating fields outside a this script no data is auto entered in since the $name or $uid is not currently scoped.

Cheers
Stephen

I just found out you were back with your insightful (and rather amusing at times, I should add) posts, and that made my day! Welcome back.
Hello, almighty all, may this message find you productive and at peace.

Geoff, I used to declare local and global variables in Custom Functions as the result of a calculation, such as this,

$$_thePath =
	IF (
		Left ( htmlPath ; 6 ) = "file:/";
		htmlPath; 

		Eval ( Let ( [ FolderPath = Left ( Get ( FilePath ) ; Position ( Get ( FilePath ) ; "/" ; Length ( Get ( FilePath ) ) ; -1 ) ) ]; Let ( [ curDir = FolderPath ]; If ( Abs ( Get ( SystemPlatform ) ) = 2; curDir ; Substitute ( curDir ; "file:/" ; "file:///Volumes/" ) & htmlPath ) ) ) )
	);

Not long ago, I received a remark from a forum user stating that (sic) “Declaring persisting variables during the run of a custom function is extremely problematic: if you have two calculation fields using the same CF, they will overwrite each other’s variables.”
I took his advice, and decided to add an extra line of code to the calculations. Using the example above, it would then be,

thePath =
IF (
	Left ( htmlPath ; 6 ) = "file:/";
	htmlPath; 

	Eval ( Let ( [ FolderPath = Left ( Get ( FilePath ) ; Position ( Get ( FilePath ) ; "/" ; Length ( Get ( FilePath ) ) ; -1 ) ) ]; Let ( [ curDir = FolderPath ]; If ( Abs ( Get ( SystemPlatform ) ) = 2; curDir ; Substitute ( curDir ; "file:/" ; "file:///Volumes/" ) & htmlPath ) ) ) )
	); 

$$_thePath = thePath;

I believed this change would solve the problem; nevertheless, another user kept insisting this is “bad practice.”
I rely on local and global variables inside custom functions for two reasons:
1. to pass the results into fields or as scripts parameters;
2. to check, using calculation fields, for errors.

I know the over-usage of variables might add to memory heap; but, besides that, why their usage inside Custom Functions could be considered “bad practice?”

@ Micah and Geoff:
Atypical situations do exist; no doubt about that.
As I write this message, my copy of FileMaker is performing a Script that compiles data from 5565 cities — one related to the other 5564. The data compiled is:
• Geographical (city’s name, state, region, coordinates, altitude, etc);
• Distance between main and tested cities in Mi and Km (from coordinates);
• Boolean if tested city falls into main city’s range of 500 Mi.
After a five-day period, FileMaker is about 55% done.
This is despairing.

God Bless and all the best,

Edward

Thanks for the excellent follow-up – that’s by far the clearest explanation of variable scoping in FM that I’ve heard.

I’ll join you in steering clear of #2. The idea of seemingly “local” variables nebulously lurking around in my databases hurts my brane : )

Best,
Brian

Understood. I think it is a matter of style and the particulars of the application at hand. I use your method too sometimes.

Brian:

Right there with you. I was surprised too when I first discovered this. I thought $variables were “local” and $$variables were “global.” But the better terms are “script variables” and “global variables.” $variables are scoped to the currently running script, and anything you do to modify them impacts the variable in that script. When the script ends, the variable goes out of scope, and a subscript will start a new scope, and restore the old one when done.

This has two interesting implications:

1: You should generally avoid usine $variables in your custom functions unless you really intend to modify script-scoped variables. Use this:

Let(variable="foo", ...)

Instead of this (which I see now and again):

Let($variable="foo", ...)

2: Calculations that run outside a script can define script $variables that live at the top of heap, so to speak, and are in existence when no script is running. Some people use this fact sometimes, although I find it so strange I avoid it from sheer terror.

Geoff

Great post – and fantastic function.

I’ve (embarrassingly) missed something obvious along the way, because the scoping of $names is a real eye opener for me.

I’ve always assumed that anything a function did to a local variable passed to it would be confined to the function’s space, and not have any effect on the original variable itself once the function was finished. The ability to have a function operate directly on a local variable passed to it opens up a lot of new (to me : ) possibilities.

Thanks!

Brian

Set Variable[ $i ; $i+1 ]
GetValue( $names ; $i )

… unless of course I need to dwindle the list for some reason. Then I’ll head straight back here!

Thanks for the update. Interesting results. As you say, though, 25,000 is atypical. One of my favorite quotes is “Premature optimization is the root of all evil.” I tend to favor easy to write and/or easy to read over faster in most cases until I find a performance problem. And I don’t think we’ve ever had a pop-related performance problem in practice.

I fully get that “easy” is subjective though, and your point is valid. Something to keep in mind.

Thanks!

Geoff

Absolutely correct. Thanks! Fixed.

Geoff

I’ve always been a counter guy for loops so I never thought to use a pop method like this (in FileMaker anyway). I got curious and did a little performance test to see which is fastest. I wrote 3 scripts that iterate through a list of 25,000 values and set a field to the next value until the end of the list is reached. Here are the results:

Counter Method: 23 seconds
Pop In Loop Method: 48 seconds
Pop Custom Function Method: 52 seconds

But… the question is, how often do you need to loop through 25,000 values? When I test lists of 1,000 and 5,000, the difference is minimal. Your Pop custom function is really easy to use and keeps the script very simple, I like it!

Here’s a copy of my test file if anyone is interested:

http://www.scodigo.com/files/PopOrCounter.zip

Regards,
Micah