Jump to content

Evaluate () auto-entry behavior strangeness


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

Recommended Posts

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?

Link to comment
Share on other sites

Now, more bizarre, when the trigger fields change it DOES NOT always update itself.

What commits the record as such??? We debated this some month ago, how extensively the scattering of commit-steps should be. Even duplicate record steps couldn't live without them!!!

You have to distinguise the java scripted freshing in the browser of your dealings with the actual storage of the intended data in the database.

--sd

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

So no other values are changing, except the record ID.

What makes me wonder is the need for an autoenter field in the first place, is it to enforce the indexing needed for a foreign key??? I'm guessing here you attemt to change a global value which you then expects will update all foreign keys???

But not even in native mode (unserved) will you not be able to change anything in stored fields except for the record you're in via the change of the global field.

You have to move the multiline keying to the other side, to behave correctly must a unstored field form the key on primary side.

But unless you have a list of recuring events, might non-equijoins be a far better choise, after it has been improved significant when FM8 was released.

--sd

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Evaluate ( Quote ( MonthList ( Start_Date ; Frequency ) ) ; [ Start_Date ; Frequency ] )

It escapes me why you use Evaluate in the first place, an unstored calcfield vill evaluate accordingly, there is no need for the field to get stored, since it must reside on primary side of the relation.

Perhaps you should make a tiny template to explain your reasoning ...because what I think you're up against is updating a relation away.

These a always are tricky to establish since the ownership of the record have changed considerably since we turned into fm7, and the matter has been complicated further with fm8 by the fact that you actually leave the focus of main record if adressing somthing in it's portalrow.

But I'm afraid I'm talking to deaf ears here, since you're pretty certain that IWP is to blame for the inconsistency. I on the other hand is grasping for a straw, because I simply havn't enough to go on, except a long line of questions from people unvilling to use unstored calcfields, and a craving desire to over-exploit (abuse) Evaluate(

If you wish to test how far a global field or a field a relation away can change the Evaluate functions in several records. Make the records line up in a listview and make change to a global occurence in one of the records... and please observe the scope is one record only!!!! So if globals can't force freshing thru - could values depending on data a relation away - NO!

--sd

Link to comment
Share on other sites

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.

Edited by Guest
Link to comment
Share on other sites

Alright thats another matter - but the reason for using Evaluate( must then be that one of either start_date or frequency are global values, if it isn't would I make the function work straight away with the indexing turned on ...since the purpose is a straight forward search???

Let me quote

Refreshing a window (with flushing the cache or without) will NOT cause the auto-enter field to re-evaluate. It evaluates once at record creation (and that would include import with auto-enter option on). After that, it will re-evaluate only when a referenced field IN THE SAME RECORD is modified. Even if the calculation references a global field, and that global field is modified, only the CURRENT record will be re-evaluated.

From this thread: http://www.fmforums.com/forum/showtopic.php?tid/172085/post/186131/hl//#186131

--sd

Link to comment
Share on other sites

I came to think further at you problem, yes you can't make autoenters work without explicitly committing the record. So in your case - why not make it a Set Field[ that makes the list of dates by the CF and then finish the script by a Commit record.

What you miss is the ability to trig autoenters while tabbing out of the field, what you seems to be used to with native filemaker.

IWP has no contact to the record "beneath" - you're send a edit image/layout which behaves almost as if... but it's a Commit/Submit that effectuate your wishes to update something.

Read the chapter "Application Flow" in this book: http://www.amazon.com/gp/product/0789730286/102-1020497-0728929?v=glance&n=283155

What puzzeled me was that the autoenter you gave, made no sense, and why you've chosen to use autoenter instead of a straight forward calc'field.

These inconsistencies in the reasoning, are rather confusing - why should we believe your statement on the sound business logic? We're not here as worshippers or caped defenders of a holy order, but to question reasoning behind something as the source for it disfunctionality - and by it sharpen our skills!

--sd

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Read the chapter "Application Flow" in this book: Special Edition Using Filemaker 7

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Actually, evaluate wasn't working at all with the trigger fields.

Exactly, but what you have here is a violating very basic relational design issues as well, lets take one 1NF says "One fact per field" as well as the syncking issues you actually have, usually makes a developer think of one of objectives in relational designs, namely to have information stored in only one place. Why is it that you can't give the user direct accesss to alter a date or two in a portal???

Now what surprises me slightly is that, although you're mac user does it seem like you're opponent to modality in user interaction as well as methaphoric layouts??? There might be some points in the issues raised in this paper http://www.acm.org/pubs/cacm/AUG96/antimac.htm ...but my guess that webinterfaces are where we are likely to see these changes last ...due to the lack of tools and standards to depend on.

What I have done is to alter one of our templates (attached) into the way I think it should be done with the present level of tools availiable, leaving it up to user to alter the produced dates in the resulting portal, or "reshuffle" by extending the knobs to fiddle in the OTHER layout, as a kind of preemptive measure against the user makes too many mistakes!

Please note that I use $variables which only works with FM8 so if you host the solution ...are we still in the waiting for FM8SA, so you have to rework the reasoning, as well as I in the internal logic works with a european notion of which day is the first in the week.

But as you will note is that I use the evaluation of the CF as a parameter for the scripting, which makes it stored in just one place, due to the evaporative nature of script parameters!

--sd

Recur5.zip

Link to comment
Share on other sites

This topic is 6681 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.