Value List Bug in FileMaker 7

[rudy]

A value list using values from a field, displaying values from a second field. You can type the first few letters of an item to scroll straight to that item in the list. In previous versions of FM, you could sort the list by either the first or second field and the "quick scroll" worked according to which field the list was sorted by.

THE BUG: In FileMaker 7 the "quick scroll" only works on the first field even if the list is sorted by second field. If you've got a long list that makes for an awful lot of scrolling which is the whole point of the "quick scroll" feature.

Please let me know if I'm missing something here.

[DanBrill]

No, you've got it right. See this possibility...

http://www.fmforums.com/threads/showflat.php/Cat/0/Number/109852/page/0/view/collapsed/sb/5/o/all/fpart/1

[BruceJ]

DanBrill said:

No, you've got it right. See this possibility...

http://www.fmforums.com/threads/showflat.php/Cat/0/Number/109852/page/0/view/collapsed/sb/5/o/all/fpart/1

I agree. This is an awsome solution, especially when the first vlaue list was arbitrary to the user anyhow. The only concern is that the second value MUST be unique as it is used in the LookUp process (aka Calculated Value). In mnay cases this is a non-issue.

I had started to use this in an Invoice/POS solution that included mutiple stores that had similar items. Problem was, the LookUp was pulling the itemID from other stores inventory. Very embarrasing for me to my clients. Fortunately, I revamped some of the concepts and worked through the issue quickly. I still find this a valuable method in many other situations though.

[rudy]

Thanks, that's a workable solution. However, I think that this new behavior of lists must certainly be a mistake. The only way for the "quick scroll" function to be useful is if it works on the field the list is sorted by. Otherwise, it's pretty much useless. I've looked for a bug-reporting process at the FileMaker site but wasn't able to find anything. I'd really like to see this problem fixed in FM 7.01. Is there a way to let the FM people know of a specific problem like this?

[MoonShadow]

You would like to see it fixed in FM 7.01, Rudy? 7.02 is out. You might try the upgrade first. I haven't upgraded yet - I'm still on 7.01.

[DanBrill]

I'd agree, Rudy -- sorting by the second field without being able to 'quick scroll' to it is useless. And it still doesn't work the old way in 7.0v2. But I actually like my new way better.

Bruce J said:

The only concern is that the second value MUST be unique as it is used in the LookUp process (aka Calculated Value).

The weird thing is that it had to be unique anyway even in FM 6. I found this out when I had a database of churches. Each had a unique serial ID. I had a value list of the Serial ID, and also showed and sorted the list by the ChurchName. However, if I had multiple churches with the same name (and trust me, there are a lot of St. Mary's and St. John's), the value list only displayed the first one in the database, despite the fact that they had unique ID numbers. That's right -- the value list was based on the unique ID, but it dropped the value from the list if the secondary field wasn't unique too. Talk about a bug! The solution is to force the secondary field to be unique too by creating a calc field that concatenates the ID to the name. So the value list is still based on the ID, but the second/sort field is a calc:

ChurchNameSerial = ChurchName & "(" & SerialID & ")"

So having to make a unique identifier for this new lookup method isn't really any more work.

[-Queue-]

The 'uniqueness' of a valuelist item is determined by which field you sort. So it makes sense that duplicate church names would be ignored, since you were sorting (essentially summarizing) by name and not id.

This effect is highly useful in ordering repeating calculated values in ascending/descending repetition order. You set the valuelist to use the repeating calc sorted by repetition (index). Since the index values are unique, no duplicate calculation results are ignored and every possible value is treated as unique. This makes parsing data and reassembling it in the correct order a breeze.

The only problem is that it doesn't work for self-related records in 7 yet, only tables as a whole. But I'm patiently waiting for the fix.

[Tony Adkins]

You are exactly right! FMP 6 had the "quick scroll" feature. FMR 7 does not... at least not yet. For all of the thousands and thousands of power users out there that have large db's, with say tons of parts, inventory, etc., this is a MAJOR problem. When we upgraded from v5 to v7, I would expect more, not less. I am sending a msg to FMP to put back that functionality in the 7.xv rev.

The more users that respond to this problem, hopefully the faster they will put back the functionality.