You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment we have default values that can be applied when editing. Depending on the expression, they could depend on all attributes or they could refer to other attribute values. If this is the case, the values are updated "real time" in the form. Still, there are other expressions that do not update the widget values "real time", but can lead to new values (such as now(), rand() etc.). These are updated when the form is closed (i.e. on OK, or in the attribute table on index change). This keeps the performance stable, but it can be confusing for a user that the stored values differ from the values they saw in the form before.
Therefore, at least an indicator would be nice to show the user that these values are volatile.
Volatile vs. depending widgets
Here I call the widgets that are updated "real time" dependent widgets. Their expression refers to other attributes on which they depend, or functions that depend on "all_attributes".
All other widgets that contain functions in their expressions are called volatile. Not only now(), rand() (although they are mostly affected), but also other functions that could lead to a value change after the update.
"Apply default values on update"
Usually default values are applied on creating a new feature. With this setting they are applied on update.
More info about behavior of "Apply default values on update"
On Add Feature
Create and form opens:
normal-default-values are set
apply-on-update-default-values are set (all of em)
Changing a value in the open form:
normal-defalt-values are not reset
apply-on-update-default-values are reset when they are depending
apply-on-update-default-values are not reset when they are volatile
Pressing "Ok":
normal-defalt-values are not reset
apply-on-update-default-values are not reset when they are depending
apply-on-update-default-values are not reset when they are volatile (because they are set on form opens)
Identify and open Form
Form opens:
normal-default-values are not reset
apply-on-update-default-values are not reset (all of em)
Changing a value in the open form (only possible in edit mode):
normal-defalt-values are not reset
apply-on-update-default-values are reset when they are depending
apply-on-update-default-values are not reset when they are volatile
Pressing "Ok":
normal-defalt-values are not reset
apply-on-update-default-values are not reset when they are depending
apply-on-update-default-values are reset when they are volatile
Attribute table form view
Selecting feature and form is visible:
normal-default-values are not set
apply-on-update-default-values are not set
Changing a value in the open form (only possible in edit mode):
normal-defalt-values are not reset
apply-on-update-default-values are reset when they are depending
apply-on-update-default-values are not reset when they are volatile
"Changing feature selection":
normal-defalt-values are not reset
apply-on-update-default-values are not reset when they are depending
apply-on-update-default-values are not reset when they are volatile
This here is the behavior that should be - but still, there is a bug qgis/QGIS#56174 but this is not the scope here
Proposed Solution
Having an indicator marking all the widget where the values could change after closing the form.
Proposed icon is dark-grey ⤭ but open for alternatives
Affected Files
This is only prototype hacking. For a productive sollution, we might consider the use cases (add feature, where the values do not change on "OK" vs. edit feature).
qgsattributeformeditorwidget.h
/** * Set volatile status*/voidsetVolatileStatus();
[...]
QLabel *mVolatileLabel = nullptr;
qgsattributeformeditorwidget.cpp
voidQgsAttributeFormEditorWidget::setVolatileStatus()
{
mVolatileLabel->setText( QStringLiteral( "<font color=\"#4f4f4f\"><b>%1</b></font>" ).arg( QChar( 0x292D ) ) );
mVolatileLabel->setToolTip( QStringLiteral( "This value could be reevaluated on closing the form\nbecause of the apply default value on update functionality") );
}
(mVolatileLabel is coded like mConstraintResultLabel)
QGIS Enhancement: Indicator on volatile default values
Date 2023/02/09
Author Dave Signer (@signedav)
Contact david at opengis ch
maintainer @signedav
Version QGIS 3.36
Summary
At the moment we have default values that can be applied when editing. Depending on the expression, they could depend on all attributes or they could refer to other attribute values. If this is the case, the values are updated "real time" in the form. Still, there are other expressions that do not update the widget values "real time", but can lead to new values (such as
now()
,rand()
etc.). These are updated when the form is closed (i.e. on OK, or in the attribute table on index change). This keeps the performance stable, but it can be confusing for a user that the stored values differ from the values they saw in the form before.Therefore, at least an indicator would be nice to show the user that these values are volatile.
Volatile vs. depending widgets
Here I call the widgets that are updated "real time" dependent widgets. Their expression refers to other attributes on which they depend, or functions that depend on "all_attributes".
All other widgets that contain functions in their expressions are called volatile. Not only
now()
,rand()
(although they are mostly affected), but also other functions that could lead to a value change after the update."Apply default values on update"
Usually default values are applied on creating a new feature. With this setting they are applied on update.
More info about behavior of "Apply default values on update"
On Add Feature
Identify and open Form
Attribute table form view
This here is the behavior that should be - but still, there is a bug qgis/QGIS#56174 but this is not the scope here
Proposed Solution
Having an indicator marking all the widget where the values could change after closing the form.
Proposed icon is dark-grey ⤭ but open for alternatives
Affected Files
This is only prototype hacking. For a productive sollution, we might consider the use cases (add feature, where the values do not change on "OK" vs. edit feature).
qgsattributeformeditorwidget.h
qgsattributeformeditorwidget.cpp
(
mVolatileLabel
is coded likemConstraintResultLabel
)qgsattributeform.cpp
Performance Implications
Not expected.
Backwards Compatibility
Affects only the layout, so no issues here.
Votes
The text was updated successfully, but these errors were encountered: