Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

Bug in GetRepetition?


This topic is 7848 days old. Please don't post here. Open a new topic instead.

Recommended Posts

I need to copy the values from one repeating field to another. The script I wrote looks like this:

[color:"#666666"]

Set Field ["Field_A","GetRepetition(Field_B; 1)"]

Set Field ["Field_A"-2,"GetRepetition(Field_B; 2)"]

Set Field ["Field_A"-3,"GetRepetition(Field_B; 3)"]

Set Field ["Field_A"-4,"GetRepetition(Field_B; 4)"]

Pretty obvious, however in Field_A only the first value appears, repetitions 2-4 don't show up.

I'm using FM Dev 6.0v3. Is this misbehaviour known as bug?

To solve this issue I'm currently copying the value into a global text field first:

[color:"#666666"]

Set Field ["gBuffer","GetRepetition(Field_B; 1)"]

Set Field ["Field_A","gBuffer"]

Set Field ["gBuffer","GetRepetition(Field_B; 2)"]

Set Field ["Field_A"-2,"gBuffer"]

...

Doing it this way works, although it's quite annoying. Strange, isn't it?

Link to comment
Share on other sites

You'll find that there's an article on the FMI Kbase which acjnowledges this 'limitation', though it stops short of calling it a 'bug'. For interest's sake, the article in question is no 104269 and is accessible online at:

http://www.filemaker.com/ti/104269.html

It suggests the global field work-around that you've already discovered.

However, as was pointed out some time back (on another thread in another place) by the inimitable dj, there is an alternative - and rather more elegant - workaround:

Set Field ["Field_A","GetRepetition(Field_B; 1) & "" "]

Set Field ["Field_A"-2,"GetRepetition(Field_B; 2) & "" "]

Set Field ["Field_A"-3,"GetRepetition(Field_B; 3) & "" "]

Set Field ["Field_A"-4,"GetRepetition(Field_B; 4) & "" "]

For reasons which are somewhat obscure, this will work every time. Inclusion of a null after the referenced value apparently invokes a different part of the application calc code, and gets past the specious prohibition on extending referencing of repetitions on both sides of the script command.

Link to comment
Share on other sites

However, as was pointed out some time back (on another thread in another place) by the inimitable dj, there is an alternative - and rather more elegant - workaround:

Kewl! As I heavily use this procedure, getting rid the extra script step saves a huge amount of time. I'll give it try.

Thanks smile.gif

Link to comment
Share on other sites

I use repeating fields in this case to handle localization strings for dialogs, value lists, graphic elements and so on. I seriously doubt that switching to related files & portals make things easier.

Link to comment
Share on other sites

OK, time for me to buy into this one...

I am a long-time anti-advocate of repeating fields, and normally only use them for storing background colours and graphics. However, I found the following situation interesting:

In one of my mountain bike race timing systems, the Finish Timer display screen shows the name, race category and time for the 15 most recent riders to finish. This is a waterfall type display which is automatically updated evey time another rider crosses the line.

Now, the conventional way of thinking about this is to use a portal which shows the first 15 rows in a "show all completed laps" relationship sorted on finish clock time (descending). However, when you have several thousand people finishing a race, or when the race system is networked, sorting this portal takes a long time, so you can get the situation where the finish timer is not ready to enter the next rider.

I found that by creating a few global repeating fields, each with 15 repetitions, the system was able to produce these results quickly (in under 0.3 seconds) irrespective of the number of riders in the system or the networked status.

Link to comment
Share on other sites

Actually, I use repeating fields to store dependent value lists. I create a related file in which each record has two fields -- call 'em "Category" and "Subcategory", with the Subcategory being a repeating field.

Now I can create one record for each Category (the main value list), and use the repeating field to create the secondary value list.

But for the most part, repeating fields are garbage.

Link to comment
Share on other sites

Ok, so apart from being useful for bike race results, dependent value lists, interface images, progress bars and localisation strings, do we agree that repeating fields are garbage?

(Apologies to Monty Python's Life of Brian.)

Link to comment
Share on other sites

Hi Vaughan,

Behind the humour, there is a serious point:

A dictum based approach to development (or anything else for that matter), is not very useful - and with FileMaker can be downright counterproductive.

The fact is that there are *appropriate* times to use just about any FM feature you'd care to cite - *even* including repeating fields, not to mention the list of other popular 'whipping posts' such as printing from portals, record marking, spaces in field names etc etc.

Its fluidity and flexibility is one of FileMaker's chief assets. Folks who want rigidity and rules and fixed parameters would likely be more comfortable using some other product. One gets further with FileMaker in my experience if one puts a pause on the proverbial 'knee jerk' and appraises each case on its merits. wink.gif

Link to comment
Share on other sites

I agree with CobaltSky on this one. I have found appropriate uses for virtually every tool and feature in FMPRO - even repeating fields. You just have to be mindful of what you're going to do with the data.

For a set limit of repititions and no intention of (or very limited) data analysis or manipulation of that data, then repeating fields just might fill the bill.

The other issue that needs a little contemplation is if the data is going to be shared or ported to another data set, i.e., SQL or Oracle, or you are drawing data from one of those data sets, then repeating fields are NOT the way to go.

AND, as just about everyone pointed out, they are handy as global containers for all sorts of interface variables.

As much as some people in this forum blast repeating fields and poo-poo them, I wonder how loud those same folks would squeal if FMI removed repeating fields from the FM toolbox?

....just my 2 cents...

Link to comment
Share on other sites

Ray, dykstrl

I'm absolutely agree with you

It is not to use or not ti use some feature but when and where to use them.

Just to add something in favor of repeats, any vectorial and/or iterative calculation would be virtually impossible without them.

dj

Link to comment
Share on other sites

I was looking for just this question when I logged in this morning. I tried the null text method on on set of 40 repeating fields and it worked perfectly. When I tried to do the same for another set of 40 different repeating fields (in the same script), it failed. Any ideas?

Link to comment
Share on other sites

If the source data is number, then you cannot use a text null to prompt its transfer. Whereas adding a null to text is done with:

TextField & ""

...the way you'd 'add a null' to a numeric value is:

NumberField + 0

If you try to mix data types of the fields, or to mix the data orientation of the formula expressions - ie with constructions such as TextField + 0 or NumberField & "" the technique will fail.

You haven't said exactly what the data types of the source and destination fields were before, or are now, but I'm guessing that if you have matched the data types of the fields and it is still not working, it may be that you are trying to add a text null to a numeric value?

Link to comment
Share on other sites

This topic is 7848 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.