Populating field repetitions with list values

[Rewolfer]

Problem:

I want to populate a calculation with 5 repetitions to reflect the values of a list. The list is returned from a custom function that is parameterized with the field name. Eg:

GetMyListOf5 ( GetFieldName( Self ))

returns

value1

value2

value3

value4

value5

and should end up in the repetitions of my calculation field accordingly:

repetition1: value1

repetition2: value2

repetition3: value3

repetition4: value4

repetition5: value5

I've red of Extend() and Get( CalculationRepetitionNumber ) and tried this and that but came to no conclusion.

Thanks for your inspiration,

Rewolfer.

[LaRetta]

Hi Rewolfer,

How about

Let ( r = Extend ( yourList ) ;

GetValue ( r ; Get ( CalculationRepetitionNumber ) )

)

[Rewolfer]

Thanks for the fast reply, LaRetta!

I'm sure I tried your solution, too. But FileMaker insists on a field name (see attached image).

Any ideas to bypass that restriction?

Rewolfer.

[eos]

Let ( r = Extend ( yourList ) ;

GetValue ( r ; Get ( CalculationRepetitionNumber ) )

)

If List is already a return-delimited list, Extend () isn't necessary:

GetValue ( yourList ; Get ( CalculationRepetitionNumber ) )

nicely distributes the lines to the repetitions.

[LaRetta]

If List is already a return-delimited list, Extend () isn't necessary

Hmmmm, any non-repeater field must be extended first to be used in a repetition field/calculation. Have you tried your suggestion? Maybe I don't understand the requirement.

[eos]

Hmmmm, any non-repeater field must be extended first to be used in a repetition field/calculation. Have you tried your suggestion? Maybe I don't understand the requirement.

Extend () just literally extends a single value and supplies an array of (identical) values, and it seems that you can hook into that mechanism using a real array and GetValue().

Well, it seems to work anyway. See my screenshot.

[LaRetta]

It doesn't work for me, eos. "Extend() just literally extends a single value" ... correct. How do you think it can evaluate the second, third, fourth and fifth repetition if there is no extended value?

Rewolfer, use your CF applied to a calculation field. Extend() works on fields.

eos, your screen shot is not using a field.

Edited July 6, 2012 by LaRetta

[eos]

How do you think it can evaluate the second, third, fourth and fifth repetition if there is no extended value?

Well, Extend () doesn't work for me when you feed it a return-delimited list, so I left it away; not sure what the “it” in your sentence refers to?

Get ( CalculationRepetitionNumber ) is used as the parameter for GetValue (), so each repetition, when calculated, automatically gets the value from its associated index position in the array. What is there to Extend ()? EDIT: More precisely put: You already have an array to work with, so not only is Extend () not necessary, it would give you five repetitions of the entire array.

[LaRetta]

Well it seems we are disagreeing on different criteria.

A field must be extended; hard-coded values do not. But how are those values going to get to the field? You may be right that the values returned from the CF can be used directly.

BTW, by the 'it', I mean the resulting calculation.

[eos]

Well it seems we are disagreeing on different criteria.

A field must be extended; hard-coded values do not. But how are those values going to get to the field? You may be right that the values returned from the CF can be used directly.

BTW, by the 'it', I mean the resulting calculation.

OK, we're both right and wrong - somehow …

Extend () doesn't work (at least in my setup) with hard-coded lists, but - and here I must correct myself - when used with a list in a field, is clever enough to do what GetValue () does, and supply for each GetRepetitionNumber only the associated line, not the entire list.

So I guess it depends on how you supply the raw data and if you need to use this functionality in a calculation field, or e.g. within a script to set repetition values.

[LaRetta]

Agreed. I am no Repetition Master (where is Comment when we need him)? But I DID learn that fields must be extended and I am not sure how else Rewolfer can obtain the results of his CF unless via calculation. There may be a way without a calc but I wouldn't know it, sorry.

And thanks for speaking up, Eos, these are important points. I also know that this works: GetValue ( List ( Child::Field ) ; Get ( CalculationRepetitionNumber ) ) ... which has struck me as strange since it is a field (value). So related values and Get() functions don't need to be extended either.

[Rewolfer]

Thanks to you both for the detailed reply. What eos suggests is almost what I'm looking for. My case is a bit more complicated since I need to populate the repetitions of a global calculation field.

I attached a demo of my scenario:

A global field switches the source of data for a related calculation field. The value of this calculation field is send to the custom function and returns the list data that should end up in the repetitions of the global calculation field.

In short: I want to switch the data in global repetitions by selecting the first global field. I hope a glance on my attached file shows the problem: only the first repetition changes.

This scenario looks twisted but believe me: it's a simplified version of what I'm up to. I need the global repetitions for display only. No data entry / interaction required.

Thanks in advance for your ideas,

Rewolfer.

PS: The solution should work in FMP 11 and later.

demo.zip

[eos]

Try this. I tried to make the setup a bit less complicated by feeding the calc field an already processed list, and also changed the repetition field storage from global to unstored, so it updates when you switch records. If the field must be a global, you need to find a method to have it refreshed, maybe via a trigger.

Also check the CF, the second parameter is unnecessary, which might or might not have any side effects.

demo_hopefullyImproved.fp7.zip

[Rewolfer]

Thanks for your reply, eos. But as I said: I need it to be a global calc. Only global fields can be placed anywhere without relation. An unstored calc field would show «unrelated table». This solution is part of a labelling system.

The source field data and custom function I really use is far more elaborate (pulls strings from JSON-objects) but essentially delivers a list. The extra parameter was part of a test to make sure the data is updated (I also tried "Evaluate") since global calcs from different tables won't update without "tickling".

Trigger is not an option: this solution should switch labels over several files by only selecting one field. The first repetition would hold a long version, the second repetition an abbreviation etc.

Greetings from Berlin into the deep south,

Rewolfer.

[eos]

I guess it doesn't make sense to give further advice without knowing the actual system. Just two things: why do you have a pipe-delimited list, only to convert it into a return-delimited one and put it into a repeating field? Either the list is hard-coded, then you can use CRs in the first place, or it is generated from field data, in which case it is / you can make it return-delimited in the process. And: why not use a simple text field for the display? Offhand, I can't see which advantages a repeating field offers.

Anyway, greetings to the capital! :smile:

[bruceR]

A global calc field needs to only reference globals.

demoB.fp7.zip

[Rewolfer]

I could track down the problem to this:

Fill the repetitions of a global calc field with the values coming from a List ( related field ).

On first start all repetitions get filled with values. When I switch the related data only the first repetition reflects the switch, the rest doesn't update. Unstored calculation is NOT an option; it has to be global so I can place it anywhere in my solution.

Have a look at the attached file.

Thanks for any insight,

Rewolfer.

demo3.zip

[eos]

Have you looked at the file BruceR posted in #16?

[comment]

Unstored calculation is NOT an option; it has to be global so I can place it anywhere in my solution.

A global calculation is always stored and the problem with using a stored calculation is that it will not refresh when related values are modified. If you can live with this limitation, try =

Let ( [

i = Get ( CalculationRepetitionNumber )

] ;

Case ( i ≤ Count ( values::ID ) ; GetNthRecord ( Extend ( values::value ) ; i ) )

)

Note that the intermediate List() calculation is not required.





Alternatively, you could also use =

Let ( [

trigger = Extend ( gID_F )

] ;

GetValue ( List ( values::value ) ;  Get ( CalculationRepetitionNumber ) )

)

The difference is in the way empty values will be handled.

A global calc field needs to only reference globals.

Never heard of this.

Edited July 7, 2012 by comment

[bruceR]

Yes, my global calc statement is too short. So let's expand on that a bit.

A non-calc global field is a field that can be visible in any context and in any file which contains a table occurrence for the table it occurs in. You don't need to have any layouts based on the table occurrence. The value you see displayed will always be the same and the result of an edit in any context will be the same.

However, a global calc field that IS context dependent will NOT display identically in all contexts. For instance let's take a global calc, defined within table Contacts, as

gCalc = gNum & " - " & get( recordNumber) & " - " & Contacts::ContactID

Besides placing this field in Contacts, place a copy of this field in a different file; say file "Test".

You would need to create an external data source reference in Test that points to "Contacts"

You would need to create a table occurrence in Test that points to the Contacts table.

Set up no relationship in Test that connect to Contacts.

Display field gNum gCalc in Test.

From your layout in Test, Change gNum.

Example result:

1- 0 -

Go to file Contacts and change gNum.

Example result

1 - 3 - 43

[comment]

a global calc field that IS context dependent will NOT display identically in all contexts.

That's not what I see. Even in your example, the global calc field displays the same value in both files. Of course, the value may not be what you would expect - but it is the same value nevertheless.

Other than that I fail to see the relevance of your example to Rewolfer's issue. I am guessing this is some kind of UI device - perhaps selecting the language for labels. As such, I would expect the (global) choice to be made once in some type of preference record, and not touched any more - certainly not through another file.

[bruceR]

The relevance is that Rewolfer posted a file with an attempt at global calc that didn't work; for the reasons discussed.

I posted an example file using a global calc based entirely on globals, which solves exactly the problem he is trying to solve.

[bruceR]

Rewolfer Demo3 converted to auto-enter global.

demo3B.zip

[comment]

Rewolfer posted a file with an attempt at global calc that didn't work; for the reasons discussed.

If that was the reason why it didn't work, then my suggestions would not work either. However ...

[Rewolfer]

Thank you all for the intense discussion of this issue. Unfortunately none of the solutions fits my application.

May be I formulated my approach too general.

This issue arose when I tried to elaborate on my (working) labelling system. I have a table of fields containing all existing label names as field names. In a second table the user edits the language dependent values. When I switch the language ID the array of language values changes. Fields in the first table evaluate their content by looking up the key-value-pair in the array.

So far this works perfectly. I hoped I could enhance this solution by adding additional fields per label name in the second table (eg: abbreviations of labels) and have them evaluated in field repetitions in the first table thus eliminating the need for more tables.

That's why I need to have the field repetitions to evaluate as a global calc. I can use them anywhere by only placing a table occurrence of the first table and use merge fields on layouts.

what I want is (only 1 table/ table occurrence involved):

<<label::label name1>> = label value1

<<label::label name1[2]>> = short label value1

<<label::label name1[3]>> = other information about label value1

what works so far is (3 tables + 3 table occurrences necessary):

<<long label::label name1>> = label value1

<<short label::label name1>> = short label value1

<<other information of label::label name1>> = other information about label value1

I attached a demo to illustrate my issue,

Thanks in advance,

Rewolfer.

demo4.zip

[comment]

Does this work for you?

demo5.fp7.zip