Conditional Value List doesn't update until exit

[jasonwood]

I can't recall if this happened in 6, but in 7 I've noticed that a conditional value list will not update until you exit the record (if you've changed the contents of the field on which the condition is based for example).

I guess this makes sense, since the change hasn't been comitted yet, but you'd think they'd write a workaround for something so obviously useful.

Any comments? is this a bug? or a feature?

[Vaughan]

Does changing field (as opposed to exiting record) work?

[jasonwood]

Nope, after changing the key field, I've tried tabbing back and forth, and clicking to different fields, the conditional value list still shows items consistent with the previous value in the key field.

If I click the background then go back to the conditional value list, it will now show the new items consistent with the new value I put in the key field.

[Vaughan]

Is the layout set to save the record without prompting?

[jasonwood]

yeah.

are you not having the same problem?

[Vaughan]

I haven't done that much with FMP 7 yet. Thanks for blazing the trail for us Jason!

[QuinTech]

Well, i think i'll call it a feature. Because the alternative, it seems to me, is to commit the record before the user has exited the record. That's good for the value list, but it seems like that would take away the ability to undo changes to a record, which is a feature of 7 i really, really like. Unless there's a middle way where the record is partially committed somehow... ?

Jerry

[jasonwood]

Well even if your changes are not comitted to the file, they are stored somewhere.

Note that it works if the field was previously blank (and committed that way). You enter data into the previously empty key field, tab to the conditional popup, and all works, but if you go back and change the key field, this is when you run into trouble and have to exit the record again.

Now that I've noticed that it works the first time, I'm prepared to say this is in fact a bug.

[jasonwood]

I've submitted a "problem report" to FMI, FYI, LOL

[Reed]

Maybe you could attach the file so users could trobleshoot it. Here is a file I just made where the name field is a dynamic value list. It seems to update fine when the key is changed without committing the record

valueList.fp7.zip

[QuinTech]

jasonwood said:

Now that I've noticed that it works the first time, I'm prepared to say this is in fact a bug.

Well, in that case then i'd agree with you. BTW, this does not happen in v6. Then again, the commitment happens immediately in 6.

J

[jasonwood]

Hi Reed, that's interesting - it works.

I created my own new test file and it works too. But I have the problem occurring multiple times in my original file. I'm wondering if this has something to do with the fact that this file was created before the latest FM update... I hope not! Saving as a clone didn't help.

I'll keep looking into this tonight to see if I can find anything different about my original database. You'd think if I did something wrong it wouldn't work at all.

[Reed]

I just remade my file from scratch with a copy of fm7 preview 7.01a (The first was with dev 7.02)

It still seems to work just fine

Does your solution involve global fields? I think that sometimes globals don't update right until the record is commited. can anyone else confirm this?

[Reed]

I just saw a video on auto-reducing value lists on filemakermagazine.com. The solution presented there uses unstored calcuations as part of the value list interface. These require record commitment to update. Do your value lists contain unstored calcs?

[jasonwood]

nope, I don't think calcs or globals could be to blame.

I must be missing something silly.

I've taken appart the database and left only the relevent layouts & tables remaining. Maybe someone could take a look (see attached)

On the invoices layout, you can do two things to see this problem:

enter an account number for billing then use a conditional value list to select a contact

enter an account number for shipping then use a conditional value list to select an address

SOSValueLists.fp7.zip

[Reed]

I can't figure out why your's doesn't work. I guess I'm just too tired. I did take another look at filemaker business tracker. It has a similar invoice layout with value lists for multiple billing, shippping addresses. Theirs seems to update the lists fine when changing the company ID without a commit. I think it must have something to do with the relational structure.

I noticed that your addressID field is not a unique ID. Is there a reason for that?

[jasonwood]

Yeah, the addressID, contactID and phoneID start at 001 for each account and go up from there

Just for fun I deleted the address record for the second account so there would be no duplicates and it still doesn't work.

I can't figure out why your's doesn't work.

I'll take that as an "I'm not crazy after all". Thanks.

[jasonwood]

Well I'm just about ready to give up - but it's so hard knowing that this isn't supposed to be happening.

I've simplified the demonstration a bit and added some narration so if anyone is up for a challenge, the attached file should show the problem pretty clearly!

SOSValueLists copy.fp7.zip

[Reed]

Well you can buy me a beer next time I'm in Canada

I changed the value list definitions to starting from: Accounts

Now everything appears to work properly.

Dana

P.S.

I previously had a similar problem when filtering portals. If the global filtering the portal was from a table not represented by the layout where the portal was placed, then the portal would not refresh when the global was changed.... until I changed to another record and then back, or until I did set field[] on the fields that were involved in the relationship.

SOSValueLists copy.fp7.zip

[jasonwood]

SWEET!

I never would have thought of that. In fact I wouldn't have expected that to work at all, since the chain of relationships really begins at Invoices, where the account number is entered, then follows back through Accounts to Account Addresses (or contacts).

Have I misunderstood what they mean by "starting from..."?

Most importantly though, it works, and I will be eternally grateful!

[Reed]

I thought that too, but then I read the online help (RTFM) and it stated:

To include only related values in the value list, choose Include only related values, and choose a related starting from table from the list. The value list will only display field values from records that satisfy the relationship criteria specified between the starting from table and the table containing the field selected in the Use values from first field list.

Anyway, glad I could help, and learn something too in the process.

[jasonwood]

Uh oh...

That only works for one of the two relationships, depending on which TO is used for the current layout (I have two independent relationships to the same table, so that I can ship to a different account than I'm billing from).

Isn't that annoying that everything works when you do it my way except you have to exit the record to update the value list. Your way corrects that problem but introduces a new one. I'll have to put the shipping address on a separate layout that blocks access to the billing contact.

Doh!

[jasonwood]

Well, to clarify, it only stops working when you're shipping to a different account your billing from.

Based on that exerpt from the online help, I would still say (perhaps more confidently than ever) that this is a bug.

[Reed]

Could you make a second value list for the other TO?

I can see shipping to a different address than you're billing to, but a whole different account? How often does that get done?

It may still be a bug though, just like some of the portal refresh ones, and the type ahead behavior for the second value in the dislpayed value list, and the fact that the second value doesn't show in Instant web publishing and.....

[jasonwood]

Yeah, it is a second value list. That doesn't help much, except I could set one up to do it my way which causes the problem I was having only to occur in one of the two places.

Actually, this happens a lot, but almost exclusively for LEASES.

The leasing company is the billing company/contact/address.

Shipping address is for the customer.

It also happens in my purchasing module when I do a "Drop Ship". The supplier is one account on the invoices, for which I want to choose a contact for the order. I then want to be able to select a customer account and corresponding address for the ship to.

[Brewser]

Hello, I am having the exact same problem as Jason. I have downloaded all 3 files and I can't figure out what had changed other than the layout. You mentioned you moved the accounts in the value list. Could you explain this. I don't see it. The value lists from all three files look the same. I am in the same boat with the refresh list.

Thanks