Hi BramG,

The cursor_to_col_id variable is intended only as an output parameter, to steer the user to a certain input field based on other input.

There is no guarantee that the cursor is placed in another input field when the Default logic fires on input change. Furthermore, the user is free to move focus to other fields while not modifying data. In this situation, the Default logic would never even trigger.

Allowing cursor_to_col_id as input would imply the Default logic has a reliable way to know when a certain field gained focus. This is not the case.

Okay, that answers half of my question, thanks!

I also have default logic that triggers on ‘@cursor_from_col_id is null’, so when the form is opened and the user has not yet changed fields. However, the logic wrapped in this condition is not executed, because the cursor_from_col_id is immediately filled out, as shown in the database event logs. Can this be explained by configurations in the model or in any other way? As i recall, checking wether the @cursor_from_col_id is filled out is pretty common practice, right?

Yes, the caveat being that @cursor_from_col_id is only set to null when the user is adding a new row or copying an existing row.

When the user starts editing an existing row, the platform does not fire Default logic until any field is modified by the user.