Update widgets with default values on attribute form

[signedav]

Updates widget values on real time while editing the referenced fields.

To avoid recursion it stores the currently updated fields index in mAlreadyUpdatedFields. The widgets contains as default value the value of the previous one plus 1:

To Do:
-[ ] Testfunction in testqgsattributeform

[m-kuhn]

Would qgsVariantEqual take care of all that?

[signedav]

It would care for the case that when a NULL value changes to 0, but for what is mentioned in the comment (I took it from saveEdit because there the behavior is the same) qgsVariantEqual does not care for the case when a null value does not change, but "two null qvariants will be reported as not equal." This would mean both are isNull but the comparison is not true. This could be solved by changing the qgsVectorEqual as this:

  return lhs.isNull() == rhs.isNull() && lhs == rhs || ( lhs.isNull()  && rhs.isNull() ) ;

But I'm not sure about it.

[m-kuhn]

I think lhs.isNull == rhs.isNull already takes care of exactly this.

[signedav]

But the && lhs == rhs makes it false again. When we pass two NULL values. the compared isNulls returns true, but are connected with the comparison that could be false (regarding to the comment).

What the lhs.isNull == rhs.isNull does is, that it returns false in the end in case we compare 0 with NULL what is nice...

[m-kuhn]

Just because of the comment or did you experience this?
In the end I think qgsVariantCompare was implemented exactly for cases like this, so it would be a pity if it's not usable here.

[signedav]

Just because the comment. That's why I'm not sure at all. But it should be same like in saveEdits and so I didn't want that I risk issues with this case...

[m-kuhn]

Let's see, the check in saveEdits was introduced in 2fddc00 (by @nyalldawson)
The method qgsVariantEqual later in 90e2c45 (by @elpaso)

@nyalldawson / @elpaso, could the above patch be merged into qgsVariantEqual?

[m-kuhn]

Basically the question is, should we add a testcase for

QVERIFY( qgsVariantEqual( QVariant( QVariant::Int ), QVariant( QVariant::Double ) ) )

I'd say yes.

[nyalldawson]

+1 to all the above ;)

[signedav]

Is it correct that qgsVariantEqual should return true in case of two NULL values from different types, but false if one of them is invalid?
Means these test are correct:

  QVERIFY( qgsVariantEqual( QVariant( QVariant::Int ), QVariant( QVariant::String ) ) );

  QVERIFY( !qgsVariantEqual( QVariant( QVariant::Int ), QVariant() ) );

With that it won't have an issue anymore on the formerly failing test for the ValueRelationWidget but what is happening here, is still a little bit weird https://github.com/qgis/QGIS/blob/master/src/gui/editorwidgets/qgsvaluerelationwidgetwrapper.cpp#L236

      QVariant v( mComboBox->itemData( i ) );
      if ( qgsVariantEqual( v, value ) )
      {
        idx = i;
        break;
      }

There it won't return true anymore if value is invalid, but still it wouldn't had returned true before also if v would not be recognized as NULL if mComboBox->itemData( i ) returns 0. So shouldn't here be set a type with e.g. toInt()?

[nyalldawson]

+1 to all the above ;)