Different Action Results with "New" vs "Saved" Data Row using Reset on Edit & Initial Values

[ScottE]

I have a project management app with a table of "Items" such as "Doc", "Phone" "Event" "Task", "Email", etc.

Each "Items" row has a ENUM field [I/O] with "to", "from", "other" as potential values.  Each "Items" row also has three (3) ENUMLIST Fields [To], [From], & [Other]

New Items are created with a LINKTOFORM, where the default values for [I/O] & [To] are "to" and a ContactID from a different table.  [From] & [Other] are always blank by default.

Desired Function: [I/O] is displayed as 3 buttons in a form and when an [I/O] button, other than the default [I/O] value of "to", is pressed, the Value of the newly pressed [I/O] button (example "from") triggers the  corresponding ENUMLIST Field ([From] in this example) to ""reset on edit" and copy the default value from the default field [To].  This same button change also triggers the default [I/O] value to "reset on edit" to a blank value.

Default Unsaved Form

My actions for the [To], [From], & [Other] fields work perfectly with a form row that has been saved, but not with the initial instance of an unsaved form newly created via the LINKTOFORM function.

In the unsaved/newly created  LINKTOFORM instance, the [To] field does not clear and looks like below

What is the difference in these two states "saved" vs "unsaved" that could cause my actions to fail?

TIA!

[Marc_Dillon · Accepted solution]

An "edit", in the case of using "reset on edit", generally just means at the beginning of an editing/form session. It is NOT evaluated every time a column is editted/input during a single form session, as you seem to be expecting it to.

Another thing. Initial values will only continue to be re-evaluated during the form session until a value is otherwise assigned to the column. Setting a value to a column with a LINKTOFORM argument negates the initial expression evaluation for that column.

My suggestion for you is to hold the initial "TO" value in a separate and hidden column, that is populated via the LINKTOFORM. Then set the initial value expressions for both the "TO" and "FROM" columns to be based off of that hidden column. I think this should get you most of the way to your desired functionality. Reset_on_edit is probably not benefitting you at all here.

[ScottE]

Thank you for the reply.

I have considered the hidden column with the initial ContactID, but have reasons to want to avoid it.  

An "edit", in the case of using "reset on edit", generally just means at the beginning of an editing/form session. It is NOT evaluated every time a column is editted/input during a single form session, as you seem to be expecting it to.

But it seems to work that way, at least for the other fields.  I can actually toggle [I/O] in the unsaved form multiple times ex. TO> OTHER > FROM > OTHER and the respective fields are copied and erased as expected.  It's just that the initially populated field doesn't CLEAR and I really don't understand why it only happens when the form is new.  Everything works flawlessly when I'm editing a saved data row. 

I have almost accepted that it cannot work after a lost day of trying, but I still don't understand why it works perfectly for saved forms, but not new forms.  

Is the default value from a  LINKTOFORM unable to be changed with an action prior to being saved?

[Marc_Dillon]

---

@ScottE wrote:

But it seems to work that way, at least for the other fields.  I can actually toggle [I/O] in the unsaved form multiple times ex. TO> OTHER > FROM > OTHER and the respective fields are copied and erased as expected. 

---

That is just Initial Value doing its job. Nothing to do with reset_on_edit.

---

@ScottE wrote:

It's just that the initially populated field doesn't CLEAR and I really don't understand why

---

Because as I just said, entering a value into it via the LINKTOFORM is just like manually entering a value, it stops Initial Value from re-evaluating for the rest of that form session.

---

@ScottE wrote:

Is the default value from a  LINKTOFORM unable to be changed with an action prior to being saved?

---

Not how you're trying to do it, no. Thus my above suggestion.

[ScottE]

I guess I incorrectly believed that once LINKTOFORM had populated the default values (and ignored the "Initial Value" formula), it's job was done and that any further edits to the form would trigger the reset and invoke the Initial Value formulas and override the LINKTOFORM values. 

Hmmm, disappointed, but thank you.

[ScottE]

Is there a variable that can recognize the state of "Saved" vs "Not Saved" Form?

[Steve]

Is this a new row?/Does this row already exist?

[ScottE]

@Marc_Dillon  I went with an ugly hack, IMO.  I populate the [I/O] field with the illegal ContactID, forcing a user to manually select "to/from/other", and thus overwriting  the default LINKTOFORM value for [I/O] with valid date.

@Steve with the new/old verification to prevent overwriting on subsequent edits.

Thanks everyone!!