Ross Thompson

I would have a subscript go to the related records in the portal and step through them, appending the data from each child record to the global field. I posted this as the above response was being posted, and ended up second. But I agree with the get nth record approach. That's a good way to go.

Here's one thing I've learned: If there are two instances of a field on a layout in IWP, one will override the other. I had added a non-checkbox instance of PubDates to troubleshoot early on, so I could see the actual contents without the filter of the values list of the checkbox version. This is what was causing PubDates to constantly "update" itself. I was changing the checkboxes, but the plain version was overriding my change and it looked like the evaluate function was still being called. Actually, evaluate wasn't working at all with the trigger fields.

I've read that chapter, several times. It's been a big help as I incorporate an IWP interface. It mentions problems with Lookup fields, and from that I inferred there would be a similar problem with Evaluate (trigger field). But it still doesn't explain the behavior I'm seeing. Oh well, perhaps I just need to change my approach slightly: leave PubDates blank and if the user doesn't checkoff the desired dates, build it in the script at commit. Not as visually interactive but what can you do?

I didn't want to get into a lengthy description of the reason, but you asked for it: Users are creating contracts for advertising that can range from 1 to 12 insertions. The insertions will be related records (children of the contract). Each insertion needs a publication date (PubDates). In our current FM 6 solution, the user can create a contract specifying start date and frequency and end up with a contract that has insertions for the start date and each successive month up to the frequency. BUT, some contracts are not consecutive months and so the contract must be modified after creation; actually the individual insertions are modified by changing their pub dates. In the new version being built in 8, I am allowing them to specify the exact desired pubdates at creation. For standard contracts my custom MonthList function will build a list of consecutive dates based on start date and frequency, then at commit the child records are created for each date in the list. The list is in the PubDates field of the contract. The PubDates field is editable on the contract creation screen and displays as a checkbox field that shows the next 12 months from the start date. The idea is to not require them to check the dates desired if it is a standard contract (let MonthList do the job) but allow them to change some dates if it's a non-standard contract. Further complicting matters is the possibility that the user will change the frequency or start date before committing the contract, so PubDates should auto-rebuild if one of those values changes. THAT is why I used Evaluate; so I could use Start Date and Frequency as triggers. This all works just fine in native Filemaker, but as I keep repeating, in IWP PubDates refreshes itself every time the record is committed, even if Frequency and Start Date have not changed. And furthermore, through testing with special mod-timestamp fields for each of these three fields I can see that Frequency and Start Date are NOT being reset by the commit in IWP. I'm going to do some more testing today to see if I can affect this strange behavior.

We're not dealing with related records, yet. The problem is occurring in a single record. All referenced fields are within the single record. Don't worry about why, there is a sound reason based on business logic and user interaction needs. All I am asking is if anyone else has seen odd behavior with IWP and Evaluate. I'm not looking for you to try to guess what I'm doing and suggest alternate approaches.

The month list is used to generate child records. The methodology is sound. It works perfectly in native Filemaker, just not in IWP. Has something to do with the way record changes are stored via IWP and how that affects trigger fields. Has anyone else experienced odd behavior through IWP with auto-entry calcs that use Evaluate with trigger fields?

I have found that if you have a two-file solution, and both have been opened in the session, Exit Application does not log the user out of both files. Strange behavior results. If you add a "Close Window" step to close the virtual window of the other file, it works. Also, login should be restricted to the main file and the other(s) should not appear on the IWP home page.

A couple of buttons can commit record changes. In each case the record's ID is set to itself, then commit occurs. (This to refresh a portal.) I can click this button repeatedly, without changing anything in the record, and PubDates will reset itself each time (I can tell by the timestamp field with PubDates as the trigger.) So no other values are changing, except the record ID. I do use Commit frequently, even while in the same record, to make sure dependencies are properly established when related values are being used to set fields.

Using Evaluate with trigger fields to auto-enter data via a custom function. Behavior in IWP is strange. My custom function ("MonthList") builds a list of dates from two parameters, Start Date and Frequency (number of dates). The field that gets updated ("PubDates") has this for auto entry calc: Evaluate ( Quote ( MonthList ( Start_Date ; Frequency ) ) ; [ Start_Date ; Frequency ] ) So if Start_Date or Frequency fields change, the month list gets rebuilt in PubDates. User can alternately change the contiguous list of dates through checkbox entry directly in PubDates. As long as the number of checked dates still equals Frequency and Start_Date is still first, this is allowed (controlled through scripts). And as long as Frequency and Start_Date are not changed, the user-selected PubDates hold. EXCEPT in IWP interface. In IWP the PubDates field ALWAYS updates itself, even if Frequency and Start_Date have not changed. I've checked this with special timestamp fields for each of the three fields. I have tried to make the auto-entry calc conditional for non-IWP users, and conditional based on a separate override checkbox field. These are all ignored and the PubDates field continues to update itself. Now, more bizarre, when the trigger fields change it DOES NOT always update itself. In regular Filemaker client interface everything works as it is supposed to. Anyone have any insight into this?