Family Historian User Group

A recent FH Mailing List dialogue suggested that User Defined Macros for Expressions would make the exchange of complex Data References and Functions more reliable and convenient. This would allow 'experts' to create sophisticated expressions, or partial expressions, that others could use, without the risk of introducing basic syntax errors.
Although User Defined Macros look like Functions, they actually use simple text string substitution logic.
So for example =SpouseName() could be defined as %INDI.~SPOU[$1]>NAME[1]% where $1 represents the 1st macro parameter.
Thus:
=SpouseName(1) would become %INDI.~SPOU[1]>NAME[1]% the 1st spouse.
=SpouseName(2) would become %INDI.~SPOU[2]>NAME[1]% the 2nd spouse.
=SpouseName(3) would become %INDI.~SPOU[3]>NAME[1]% the 3rd spouse.
(If an actual $ character were needed then it would be represented by $$.)

To allow a list of spouse names with space separators it could be defined as %INDI.~SPOU[$1]>NAME[1]% . '   '
With the =CombineText() function and custom separators it would be =CombineText( $2, %INDI.~SPOU[$1]>NAME[1]% )
So for example =SpouseName(3,' & ') would become =CombineText( ' & ', %INDI.~SPOU[3]>NAME[1]% )

Alternatively, a complete spouse name list Macro called =AllSpouseNames(&) could be defined as
=CombineText(,%INDI.~SPOU[1]>NAME[1]%,CombineText(' $1 ',%INDI.~SPOU[2]>NAME[1]%,CombineText(' $1 ',%INDI.~SPOU[3]>NAME[1]%,CombineText(' $1 ',%INDI.~SPOU[4]>NAME[1]%))))



ID:5495

As the originator of the original thread, I thank Mike for supportively picking up the ball and running with it. Although I agree that my original concept describes a system of text-substitution macros, I nevertheless feel that the name 'user-defined functions' (UDF) is more appropriate: they should look and behave like system functions, and to call them macros would only confuse the vast majority of FH users.

The use of $1, $2 etc to reference the parameters passed to the UDF is a good scheme. My primary concern is that it should be possible to test the 'type' of the value being passed, and take action accordingly. For example:
if NullParam($1) then B else C
or any alternative syntax that can detect what the user has passed -- a number, text, date, item, or nothing at all.

Unfortunately, the initials UDF already represent Uncategorised Data Fields.
Perhaps Custom Functions would be a suitable name.

Since the concept is macro text substitution, the checking of parameter type may be of limited benefit, because in the majority of cases the parameter will simply be a text string with a particular format, and testing the format would be impossible without suitable text string processing functions.

Also, in most cases the complexity should be hidden within the function/macro body, and the parameters should be transparently simple. If not, then the whole benefit of using them is significantly diluted.

Nevertheless, it would be possible to use existing standard Functions to check and substitute parameters. Useful Functions for this would be =TextIf(), =Date(), the =Is*** set, etc.

One useful feature would be to define default values for missing parameters. So in the above example =AllSpouseNames(&) would define & as the separator if no parameter was supplied. This example also illustrates the difficulty of type checking, because almost any text would be a valid parameter, except if it includes a ' quotes character.

Presumably these User Functions will need an = prefix when not enclosed in another Function, but NOT have the prefix when within the parameters of another Function.
This may need to be reflected in any Function defined within the body of the User Function.
I propose a special $= parameter substitution that translates to = when the User Function needs the = prefix, but translates to the empty string otherwise. So $=Function() would include or exclude the = prefix appropriately.

WL#498 has been raised for this

please vote for it here

http://www.fhug.org.uk/wishlist/wldispl ... lwlref=498