* User Defined Macros

For Wish List Requests that have either (a) been progressed to the Wish List; or (b) been classified as duplicates, or as redundant because the requirement is already satisfied within FH and/or plugins; or (c) closed because it wasn't possible to arrive at a clear specification of the request within 15 months of it being raised.
Post Reply
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

User Defined Macros

Post by tatewise »

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
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
RogerF
Famous
Posts: 182
Joined: 26 Apr 2009 16:32
Family Historian: V6.2
Location: Oxfordshire, England
Contact:

User Defined Macros

Post by RogerF »

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.
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

User Defined Macros

Post by tatewise »

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.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
avatar
Cambiz
Famous
Posts: 235
Joined: 26 Sep 2003 23:30
Family Historian: None

User Defined Macros

Post by Cambiz »

WL#498 has been raised for this

please vote for it here

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