Something to be aware of

[-Queue-]

If you don't use a Commit Records/Requests script step after a Set Field step, FM 7 will not exit the record, even if you weren't in it to begin with. This is much different than previous versions where you could take it for granted that a refresh would be forced as long as you didn't use a Go to Field [field] step in your script and had forced an exit of the record at the beginning of the script. I've only converted one file and this new feature caused it to be flaky.

Version: v5.x

Platform: Windows 2000

[-Queue-]

Something else...

Here are two files: a sample fp5 file using a repeating field for a value list, filtered by a self-relationship by id and the same file converted to fp7. Notice the value list is broken since the relationship graph displays the self-relationship as many-to-many. Can this be fixed or am I screwed?

vltest.zip

[MoonShadow]

RE: Commit Record/Request with Set Field [] ... This new feature explains probably 80% of my unpredictable script behaviors, JT. Thanks for filling us in on it. Let's hope that, once we understand how to creatively utilize it, it will indeed be a benefit and not just more work adding another script-step. I'll try to remain optimistic and believe the former.

Version: FMP 6v4, Developer 6, Server 5

Platform: Win XP, 98, 2000

[Ken Newell]

You got me on that one...I looked at both the files works what you did in v6.04 but not in 7 as built. Anyone else want to take a crack at it? This might be a case of behavior difference between versions. I'm sure many "expected" behavior issues will be brought up. I will tinker some more with it and post back if I can get it to act the same way for you. Is this a method that you use in your solutions or something that popped up as you were test driving FM7?

Version: Developer v7

Platform: Mac OS X Panther

[-Queue-]

It's a method I use quite frequently, in nearly every other file sample I post here. It seems to have been obliterated, unless there's a 'workaround' for it. I even tried creating a separate table with only an id related to the main table and the repetition field. It works fine if you use 'Include all values', but I want it to be unique to the self-relationship. If I specify to only use related values, then it only gives me the first repetition; otherwise it acts as a constant relationship and gives me all the repetitions in every record, even though they're not related based on the id to id relationship.

I guess I could go around this by hard coding all the reps into one calc, but that destroys the simplicity and dynamics of using repeating calcs.

[-Queue-]

Well, it seems the only work around is to define the repeating calculation as usual, then to create a field that concatenates them, e.g. repfield[1] & "

[-Queue-]

This workaround does not take order into account. The value list will still sort alphabetically. It appears there is no way anymore to force this nifty technique to work. Thanks, FileMaker, you've ensured I won't be updating my systems anytime soon, if ever.

[mscholtz]

I'd respectfully suggest that you're missing the forest for the trees.

The new structure allows you to create separate TABLES to hold your custom value lists, and do away with kluges like this forever. Just create a new table with two fields: Id and value - each value is a new row (record).

I mean, you could have always done it this way with previous versions, but then you needed to make a separate file for the table, which was a huge PITA in all kinds of ways. Now you can do it the way the rest of the world has always done it.

Don't get me wrong - I have my gripes about FM7. But this isn't one of them.

[-Queue-]

I think you're missing the point. If you don't specify a relationship, then FileMaker 7 uses all values for the repeating field in all records, as it should; if you do specify a relationship, then it only uses the first repetition in the related record. This is highly inconsistent. To get around this limitation, I've created a separate table containing the exact number of records as would have been repetitions. This requires adding a script that modifies all records in that table in order to perform a triggered lookup, as opposed to an automatic one in the current table that's triggered by changing a global and looks up a repeating calculation to index all values nicely. And to make it multi-user compatible, X number of related records would have to be created for each new record in the main table, where X is the number of repetitions necessary in previous versions. It's not a custom value list; it's a dynamic value list, which apparently is going to be much more difficult to create in FM 7.

One record, one repeating calculation with 53 reps, a trigger field to relookup the calc into an indexed rep field, and a valuelist based on a self-relationship replaced by an extra table, 53 records per number of records in main table, a trigger field to relookup one calculation for each of the 53 records, a script to go to the related table and force this relookup by modifying the 53 records, and a value list based on the related field...

I wouldn't definitely call the second technique a kludge; the first is simple, compact, and efficient. The second is a real pita and completely inefficient.

[Ugo DI LUCA]

Thanks JT,

You just give me the 4th reason why I won't move quickly to 7. This even calm down my anger for the OS9 issue.

I use this technique a lot actually too, and I can see the weaknesses.

Now, I don't get why it doesn't work. It seems like this is some indexing issue, as if FileMaker had changed the way indexing works.

Surely you already tried it, but what is the result given by the ValueListItems( ) in an unstored calc ?

[-Queue-]

The same thing, Ugo, just the first related repetition.

[Ugo DI LUCA]

For matter of curiosity, how do these 2 demos react to 7 ?

http://www.fmforums.com/threads/download.php?Number=94135 http://www.fmforums.com/threads/download.php?Number=96239

Thanks for testing

[-Queue-]

First one looks good. Second one seems to be dead due to the related repeating field.

[Ugo DI LUCA]

Thanks for testing them...

So this bring to a conclusion that FMI, as expected, just lowered the use of repeating fields while moving to a more respectable relational solution.

Make sense though.

[-Queue-]

It doesn't make sense though that using all values works and treats repetitions the same way it does carriage-return separated lists, but using only related values ignores all repetitions and treats the field as if it were regular. It should be either one way or the other, not dependent upon the type of value list. Putting the related repeating field on the layout displays all repetitions, so why shouldn't a value list based on it do the same?

[-Queue-]

And finally, it works, thanks to v3! See attached for converted version of sample file from March 11th, which also takes advantage of 7's functions and features.

DaysOfWeek.zip

[Ugo DI LUCA]

The problem is...your current avatar doesn't rythm the banana

Time to get your nerves out with repeats, heh !

[Ugo DI LUCA]

Hi,

Now what you can't do anymore, is to display a value from a repeating field, and also display value from another repeating field, would it be a related value list or not.

Not that I use this a lot, but it was working with 6...

[-Queue-]

Example?

[Ugo DI LUCA]

Oh well...

Again, not that I'm using it a lot.

FieldRep 1 = Mr, Dr, Pr, etc.

FieldRep 2 = Mister, Doctor, Professor.

With 6 you could have made a value list combining both fields to get

Mr Mister

Dr Doctor

Pr Professor

Well, it doesn't work anymore with 7.

[-Queue-]

Hmm, you could create a concatenated field and use that though.

[Ugo DI LUCA]

Sure, just pointing the differences between versions.

[-Queue-]

That does suck also, since you can't sort a value list based on a repeating index field anymore. So, how to keep a repeating calc based on a parsed text field (e.g. path name) in correct order when defining it as a value list? Any ideas?

[Ugo DI LUCA]

Example ?

[-Queue-]

See the solution I posted in this thread. It sorts using the repeating index field, instead of using the default alphabetical one. The same solution in v7 results in the first word being repeated instead of each item of the value list being combined.

[Ugo DI LUCA]

Hi,

That's how I handle this issue actually.

VLI.zip

[-Queue-]

That works, but it's a bit of a pain. Issues arise when numbers are included in the text also.

[Ugo DI LUCA]

The solution above would break if the sentence had numbers in it.

This one would work up to 99 words and could be extended to account for more if needed, building an alias index around, waiting for the fix from FMI.

VLI_corrected.zip

[Ugo DI LUCA]

There was a minor glitch to the former file, but I would say this one should work up to 9999 words in a texte field.

VLI_corrected2.zip

[-Queue-]

This one seems to work also, interestingly enough. Haven't tested the max words though.

VLI.zip

[Ugo DI LUCA]

*******, another glitch.

Here's a finally corrected version. Looking at yours right now.

VLI_corrected2.zip

[Ugo DI LUCA]

Yeah. Had thought abouth that one too JayTee.

[Munchie]

Talking about the original topic, another issue I have run into is that when working with Portals, if I don't use the Commit records before starting a loop, many times it will not Goto the first portal row.

I've spent 1 whole day fixing this in all of my scripts. MAJOR PITA.