Commit or Auto-Enter issue?

[LaRetta]

I’m attaching a file of a process (gleaned from Comment) which creates a new portal record. If you type a value then commit the record (click on unused area of layout), the value should clear and appear in the portal. On Mac 8.0v1, it does … on Windows 7.0v3 and 8.0v2, it doesn’t.

The inconsistency deepens as you explore further...

I have 3 layouts with three different examples. It only works if 1) the child IDs exist on the parent layout, or 2) If you uncheck ‘Save Layout Changes Automatically’ in Layouts and FORCE save the record.

Why would the fields being on the layout make a difference? Is it breaking because of the evaluation order (based upon field creation) that changed between 8.0v1 and 8.0v2? Or is it an auto-enter issue? Or is the ParentID evaluating a second time? Or is the tempID not evaluating at all because the ParentID is empty at the time?

I thought others might be interested but mainly, I just want to know because ... well, I want to understand. These types of inconsistencies allow me to peer inside FM's head a bit and I want to take advantage of the opportunity to learn.

FM needs to provide us a calculation debugger routine which shows what is happening.

UPDATE: File removed. See new file below.

LaRetta

Edited March 6, 2006 by Guest
Removed demo

[LaRetta]

I have consistently reproduced the inconsistent behavior.

I have replaced the file with the original one produced on a Mac (8.0v1) because my changes in the prior (attached) demo broke it's inconsistency and it didn't EVER clear the field after the file was modified (added additional layouts) although it did before I added the new layouts.

With this copy, when I first open it, it WORKS (using 8.0v2) It clears the value ready for the next record. If I open field definitions (of parent) and go immediately back to the layout and try again, it will still clear the field. Same if I open field definition of Child. BUT ... if I specifically [color:red]open the calc definition on the TempParentID - even if I make no change, then try it, it BREAKS and won't clear the field again ever. I have repeated it 15 times with clean file and same results. Opening the tempParentID does something to the calculation.

What FM internal change takes place when a calculation defintion is opened? Could opening the file (created with 8.0v1) with 8.0v2 (and then entering the definition) force 'the fix' that FM did on field evaluation order? I think Commit might have thrown off the logic in my testing and probably has nothing to do with the issue.

Inconsistencies smack me in the face ... and if this changed behavior holds, it could hold ramifications for many of you with your auto-enter calculations (created in 8.0v1 and upgraded to 8.0v2) so I simply must speak up. If I'm wrong, please tell me. I hope I am. Also, what is going to happen if someone goes BACK to 8.0v1 (as I was planning to do today)? I use a LOT of auto-enter calculations (which are based upon other fields added in different creation orders) ...

LaRetta

CreatorSansScript.fp7.zip

[Ohgo_Ohgo]

Hi LaRetta !

I tried in Mac FM A 8v2 .

first it did not work and wrote always to the same child record.

I saw that the temp ID’s where not cleared (was 1 and 2 ).

I deleted the Temp ID’s

after I just checked Your Calculations (option and closed again)

all 3 Layouts worked fine.

Looks to me as You expected that it depends on the order of calculation.

Also You used 8v1 and I used 8V2 where this order should have changed ??

rgds

[LaRetta]

Yes, it is precisely this version change (I believe) ... and then entering the tempParentID calc that triggers the change in behavior. Could you see how the new attached demo works for you? It was created Mac 8.0v1 and I've tested it on Windows FMA 8.0v2 and it adjusts in mid-stream (when calc is opened). Thanks for the input!

One would think the version upgrade (and when an 8.0v1 file is FIRST opened), that all auto-enter calcs would adjust but that doesn't appear to be the case. Only by opening the field definition does the change take effect? Maybe this is normal but I doubt everyone knows or understands it. And again, I'm just speculating here ... that's why I'm posting.

LaRetta

Edited March 6, 2006 by Guest
Added sentence

[Ohgo_Ohgo]

Hi LaRetta again !

Sorry made a mistake before I tryed on FM A 8V1 before not V2.

But I tryed again with FM 8V2 ( not Advanced ) works fine with me at the moment.

What we have here is "a kind of circular reference" and that always depends on the calculation order

or the calculation should be updated twice ??

PS: I still use Your first sample db. I go back to 8V1 now and see if I can get it malfunction again.

but later today, now its already morning outside in the garden !

;-)

Edited March 6, 2006 by Guest

[Ohgo_Ohgo]

Ok I could not wait.

so using FM A 8V1 now I tried opening the calculations, deleted the Parent fields on the layout. moved the field around... but it still works fein.

Actually the child layout as a Table Layout is a good place to see Your "function" working!

After I inactivated The TempId calc and tried to input a record, I got a "standing" number in the TempID field which did not go away any more after I turned the calculation on again.

Could that be actually be the "white mouse" ?

Or if any thing happens once, the calculation blocks itself out until one in this case manually delete the TempId.

But well Your problem was actually on XP !

rgds

[LaRetta]

You might have answered my question above of "Also, what is going to happen if someone goes BACK to 8.0v1 (as I was planning to do today)?" Since you tested it in reverse, you got the reverse results, ie, it was broken but fixed itself when you opened tempParentID. So either way someone moves, this change in behavior will need to be triggered somehow(?) on tempParentID? And in each case, the evaluation may (or may not) change the results.

There is certainly a version connection. Whether there is also an OS connection is still unclear. And this (field creation order) may not be the issue at all. I have gotten little response here (and few downloads) so I'm still working with insufficient data to draw firm conclusions...

[Wim Decorte]

From what I see the technique relies on the internal "chain of events" in FM, which may in its own turn depend on the creation order of the fields (like it was in FM6) but I'm not sure about it.

This needs some further testing to see if other auto-enter calc fields are affected if they rely on values in other fields.

Here's a puzzler: if you change the auto-enter calc of "TempParentID" to: "" you would expect the value in TempParentID to be cleared, but no, the value that was entered through the relationship remains in the field. What does that mean:

- the auto-enter calc fails?

- or the auto-enter calc triggers *before* the value from the parent is entered?

Edited March 8, 2006 by Guest

[Wim Decorte]

L certainly uncovered a behaviour change from v1 to v2. So if anyone relies on this technique or a variant of it, they'll need to check their solution's functionality in a hurry...