QAbstractItemModel::match bug?

[Koyi]

I have a QCombobox wich model is a QSqlTableModel populated with a DataBase table:
Integer | String
=-=-=-=-=-=-=-=
|
=-=-=-=-=-=-=-=
0 | Normal
=-=-=-=-=-=-=-=
1 | Leve
=-=-=-=-=-=-=-=
2 | Moderado
=-=-=-=-=-=-=-=
3 | Severo
=-=-=-=-=-=-=-=

the combobox works finecombo.PNG
but when I try to set the value in combo acording with the database table, I use this code

void MyComboBox::setValor(QVariant myValue)
{
QModelIndexList myFinded=this->model()->match(this->model()->index(0,0),Qt::DisplayRole,myValue,5,Qt::MatchFlags(Qt::MatchExactly || Qt::MatchWrap));
 
this->setCurrentIndex(myFinded[0].row());
}

void MyComboBox::setValor(QVariant myValue)
{
QModelIndexList myFinded=this->model()->match(this->model()->index(0,0),Qt::DisplayRole,myValue,5,Qt::MatchFlags(Qt::MatchExactly || Qt::MatchWrap));

this->setCurrentIndex(myFinded[0].row());
}

To copy to clipboard, switch view to plain text mode 

When myValue is 1, myFinded has 1 Index (corresponding to row 2)
When myValue is 2, myFinded has 1 Index (corresponding to row 3)
and so on
but when myValue is 0, myFinded has 2 Index (corresponding to row 0 and 1)
I don't understand why. Is this a bug? Or am I doing something wrong

[Santosh Reddy]

Why is 4th argument in match() 5 ?

[Koyi]

In fact I only expect to get 1 index in myFinded (the values in the table are Uniques). But the application didn't work propertly so I have increased Hits (number of hits until macht stop searching) from 1 to 5 (number of items in my table) to debug.

If myValue is other than 0, all work good, but when myValue=0 I get 2 indexes in myFinded

[Koyi]

I found the problem (not the solution)

QAbstractItemModel::match compares each value from the model with the searched value and return the indexes that match.
it uses the operator== method of QVariant, but it doesn't work fine

my table is table.PNG

QVariant var1=QVariant(0); // variant containing the integer 0
 
QSqlQueryModel *miConsulta=new QSqlQueryModel;
 
miConsulta->setQuery("Select Valor, Descripcion From myTable");
QVariant var2=miConsulta->record(0).value(0);

QVariant var1=QVariant(0); // variant containing the integer 0

QSqlQueryModel *miConsulta=new QSqlQueryModel;

miConsulta->setQuery("Select Valor, Descripcion From myTable");
QVariant var2=miConsulta->record(0).value(0);

To copy to clipboard, switch view to plain text mode 

I get
var1
value: 0
type: QVariant(int)
isnull: false

var2
value:0
type: QVariant(int)
isnull: true

but var1==var2 return TRUE !!!!!!!!!

how can a null variant be equal to anything?????????
can somebody explain?
thank's

[Santosh Reddy]

That's the way it is

bool QVariant::isNull() const
Returns true if this is a null variant, false otherwise. A variant is considered null if it contains a default constructed value or a built-in type instance that has an isNull method, in which case the result would be the same as calling isNull on the wrapped object.
Warning: The result of the function doesn't affect == operator, which means that two values can be equal even if one of them is null and another is not.

[d_stranz]

By the way, do you realize that this is incorrect syntax for OR-ing flags?

Qt::MatchFlags(Qt::MatchExactly || Qt::MatchWrap)

Qt::MatchFlags(Qt::MatchExactly || Qt::MatchWrap)

To copy to clipboard, switch view to plain text mode 

It should be this:

Qt::MatchFlags(Qt::MatchExactly | Qt::MatchWrap)

Qt::MatchFlags(Qt::MatchExactly | Qt::MatchWrap)

To copy to clipboard, switch view to plain text mode 

A simple typo like this could lead to all sorts of unexplained behavior, because the result of the logical OR (||) will probably not be the same as the result of the bitwise OR (|).

[Koyi]

By the way, do you realize that this is incorrect syntax for OR-ing flags?

Qt::MatchFlags(Qt::MatchExactly || Qt::MatchWrap)

Qt::MatchFlags(Qt::MatchExactly || Qt::MatchWrap)

To copy to clipboard, switch view to plain text mode 

It should be this:

Qt::MatchFlags(Qt::MatchExactly | Qt::MatchWrap)

Qt::MatchFlags(Qt::MatchExactly | Qt::MatchWrap)

To copy to clipboard, switch view to plain text mode 

A simple typo like this could lead to all sorts of unexplained behavior, because the result of the logical OR (||) will probably not be the same as the result of the bitwise OR (|).

Ohh my God!!!! Great mistake
but in this case, the result is the same. The problem was that operator== don't work as I espected