QSqlTableModel Setting Current Row?

[fifth]

But what exactly is the problem? The model index identifies each record just fine. If you have a relational model, you can query its relation model if you need it (although I don't know if you do).

I need to 'goto' a record within the model which is identified with a field value. The field is an auto-incremented index. I can do this by filtering, but that means navigating by next,prev,first,last does not work as I am now working with a result of 1.

I need to maintain access to all records in the table but be able to set the cursor position within the table model according the field value.

The auto incremented field will not necessarily correspond to the model row number as the model may be re-ordered or filtered by the user.

Is it possible to? :

• Filter the model data
• Create a variable pointer to the single filtered record
• Reset the filter
• Set the model index to the previously filtered record

Not really sure if I'm explaining any of this properly!

I'm not even sure if this is possible using the Qt model/view properly. I might try re-implementing the edit form with sql and populating my widgets from the result set.

[wysota]

Won't QAbstractItemModel::match() allow you to find the proper index? Anyway, wouldn't it be better if the lookup dialog returned a model index instead of the field value? If you operate on the same set of tables, it would be wise to stick with the model interface everywhere possible.

[fifth]

Won't QAbstractItemModel::match() allow you to find the proper index?

Thanks, I have things working at the moment using functions to find next, prev etc with sql. But I'll have a look into the match method, seems much simpler and exactly what I was looking for.

Anyway, wouldn't it be better if the lookup dialog returned a model index instead of the field value? If you operate on the same set of tables, it would be wise to stick with the model interface everywhere possible.

I did consider using the same model across all windows/dialogs. However, I decided against that given an example situation such as;

1. Main Client List window - user filters the records
2. Client Detail/Edit window - user creates a new record

Now, if the new record doesn't fit the filter, then from the users perspective their newly created record 'vanishes'.