Global User Functions, question...

[KeithW]

Greetings,

When you create functions, do they each individually have to be in a separate script/function file in the Code tab or can you create a script/file that has several associated functions in it?

Regards,
Keith

[Raymond Lyons]

.... can you create a script/file that has several associated functions in it?

The short answer to the above is yes. I do not have time right now to give you examples. If you need one, ask and I am sure someone will oblige (me, I'm leaving on a vacation!).

Ray

[csda1]

Keith,

You can have more than 1 function inside a UDF entry, but only the 1 with the same name as the entry is accessible from everywhere.

All the rest of the functions that are inside a UDF entry are accessible only to any other function within that UDF.

[Steve Workings]

Here's a little example that may be illuminating. Put it in it's own script and run it. You'll want to make sure you don't have other global functions named Set_name() and Show_name() to keep the confusion down.

dim global vname as C
Set_name()
Show_name()
end 

Function Set_name as C()
	vName = "Keith"
end function

Function Show_name as A()
	ui_msg_box("Hello", vName)
end function

[CALocklin]

Here's an example of Ira's comment:

FUNCTION Full_name as C ( fname as C, lname as C )
   full_name = f_upper( alltrim( fname )) + " " + f_upper( alltrim( lname ))
   IF at( " ", full_name, 2 ) > 0
      show_warning( full_name )
   END IF
END FUNCTION
 
FUNCTION show_warning as C ( name_in as C )
   msg = "This name is a 'complex' name consisting of more than a simple first and last name:" +crlf(2)
   msg = msg + name_in
   ui_msg_box( "WARNING", msg, 48 ) 
END FUNCTION

If this is saved as a UDF named "Full_name", only the Full_name function will be accessible as a Global UDF. However, the "show_warning" function can be accessed by the main function or, if there were others, by any other function within the main function.

Of course, something this simple wouldn't really need a second function. It's only an example.

FYI: The placement of the main function isn't important. The Show_warning function could have been placed ahead of the Full_name function. As long as the saved name matches one of the functions within the script, that function will be considered the 'main' function.

[csda1]

Thank you Cal for illustrating what I said.

I'll also add one other point, just to be complete.

If there is an external function name and an internal function with the same name, the internal one will be the one that is executed if called from within that code entry. It also has the slight advantage of being marginally faster than an external one.

[Stan Mathews]

Use a local udf in a scripted operation?

Thank you Cal for illustrating what I said.

I'll also add one other point, just to be complete.

If there is an external function name and an internal function with the same name, the internal one will be the one that is executed if called from within that code entry. It also has the slight advantage of being marginally faster than an external one.

Any one have experience with something like

update.expr1 = "st_decy(Prdamt)"

where update.expr1 is part of an update operation converted to xbasic and st_decy() is a udf?

If the udf is visible on the code tab, thus globally defined, the script runs to completion. If I move the function into the script it seems to work but if I rename the global function the script fails with the error

Variable update.expr1 expression - Function is not recognized.

If I add a line to the script earlier than the update, ui_msg_box("","Converted is "+st_decy("0000a")), the result of the local function is displayed.

[KeithW]

Here's a little example that may be illuminating. Put it in it's own script and run it. You'll want to make sure you don't have other global functions named Set_name() and Show_name() to keep the confusion down.

dim global vname as C
Set_name()
Show_name()
end 

Function Set_name as C()
	vName = "Keith"
end function

Function Show_name as A()
	ui_msg_box("Hello", vName)
end function

Thanx to all for the illustrations, as they say, "a picture is worth a 1,000 words" ... now I'm sure I can dig a deeper hole than I have done so far !!

Thanx All !
Keith

[csda1]

Stan,

Basically, only internal functions can only be used by internal code. You are setting a global variable, update.expr1, with a string, that contains a reference to a UDF. At some point, you are running the update function (which is external), which then does an eval() of the string. It does not have any context to the internal function and thus fails.

Thus when you move the code internally, any calls to it internally would work, but the update function is external, and use the external one. If you change the name of the external one, the update can't find it.

Is that clear?

[Stan Mathews]

As always, to the point.

Stan,

Basically, only internal functions can only be used by internal code. You are setting a global variable, update.expr1, with a string, that contains a reference to a UDF. At some point, you are running the update function (which is external), which then does an eval() of the string. It does not have any context to the internal function and thus fails.

Thus when you move the code internally, any calls to it internally would work, but the update function is external, and use the external one. If you change the name of the external one, the update can't find it.

Is that clear?

Makes sense now. I was seeing the coded operation as purely scripted but it really just establishes the variables for the tbl.update().

Thanks for the clarification.

[CALocklin]

Re: Ira's comment on speed.

Functions are always (as far as I can determine anyway) slower than in-line code. Even functions internal to a script are slower. There seems to be an "overhead" in starting the function; the internal code runs just as fast once the function is running.

So, my policy is to use functions when:
- Speed is not an issue. (Remember, we are usually talking milliseconds here so speed is usually only an issue in loops.)
- The same routine will be used in many locations and/or apps and: (a) I don't want to retype or cut-and-paste and (b) far more important, if it ever has to be changed, I only want to change it in one place.

I know Ira uses functions much more than I do. In his case, the philosophy may be more like, "If speed becomes an issue, consider eliminating some function calls."

[csda1]

Cal,

Well of course (may be obvious to some) that inline code would always be faster. But if you (not you, people in general) are creating a function that the overhead of the function call is critical to the speed, then you probably haven't partitioned the problem into a large enough chunk to be efficient.

But functions have other advantages which is why I always use them (even as a wrapper for just a regular script of code).

1. They can be invoked from expressions within Alpha 5, e.g. a calculated field expression

2. They can have a variety of arguments, allowing the same code to be used in many cases

3. Function calls by their very nature must complete before continuing in the active thread. That's not always true of in-line code. Thus they perform effectively a more reliable wait (which is probably why I never seem to have sync issues)

As for speed of in-line code, the code runs identical whether within a function or just in a script, so why not put a function wrapper around it? It is also easier to write

function_name()

versus

Script_play("function_name")

I haven't investigated the overhead of a function call versus the Script_play(), but I suspect they are closer in overhead than not.

[csda1]

Speed of UDF vs Script_Play()

Cal et al,

I haven't investigated the overhead of a function call versus the Script_play(), but I suspect they are closer in overhead than not.

I actually was surprised, but the overhead of calling a global script versus a UDF function call with identical code was not what I expected. I further ran tests with inline code, UDF code, evaluate_template() and script play(). All the code executed a simple assignment of a constant z=1. The speeds from best to worst (normalized times in seconds for the code to execute is next to them);

z=1 ' .000019124 sec
z=x() ' .00018280 sec
evaluate_template("z=1") ' .00021158 sec
script_play("y") ' .00265600 sec


Without a doubt, there is no advantage to using script_play() ever (unless required to)! It is 15 times slower than a UDF call.

evaluate template() needs to compile the code, and is much better than the script_play() but not as good as the UDF call. And of course, inline code is by far the fastest. Thus, if you have a trivial amount of code, better to include it than to call a UDF if speed is a requirement.