QListWidget, how to post a question to the user before allowing change?

SPlatten

@VRonin , Thank you, I'll look into it.

VRonin

Example:

#include <QListWidget>
#include <QApplication>
#include <QMessageBox>
int main(int argc, char *argv[])
{
   QApplication app(argc,argv);
   QListWidget mainWid;
   mainWid.setSelectionMode(QAbstractItemView::ExtendedSelection);
   for(int i=0;i<5;++i)
       mainWid.addItem(QStringLiteral("Item ") + QString::number(i));
   bool userSelected = true;
   QObject::connect(mainWid.selectionModel(),&QItemSelectionModel::selectionChanged,[&mainWid,&userSelected](const QItemSelection &selected, const QItemSelection &deselected){
       if(!userSelected)
           return;
       if(QMessageBox::question(&mainWid,QStringLiteral("Are you sure?"),QStringLiteral("Are you sure you want to change the selection?")) != QMessageBox::StandardButton::Yes){
           userSelected=false;
           mainWid.selectionModel()->select(selected,QItemSelectionModel::Deselect);
           mainWid.selectionModel()->select(deselected,QItemSelectionModel::Select);
           userSelected=true;
       }
   });
   mainWid.show();
   return app.exec();
}

JonB

@SPlatten
With all due respect to @VRonin (and I do have respect, he probably knows more than I!), this is not the way I would want to do it.

Be aware that his way allows the selection initially, and then reverts be deselecting and then reselecting. This could easily have side-effect consequences, you may well have slots on item selection elsewhere. You asked for:

If the user answers one way then the selection is allowed, however if the user answers the other way I want to stop the selection and keep the existing selection.

[My bold.]
For that behaviour, I like @Pl45m4's suggestion of writing your own custom selection model....

SPlatten

@JonB , @Pl45m4 , @VRonin , I am creating an engine which will allow anyone to write applications without any knowledge of Qt or low level programming languages. The framework is created in XML, where there XML defines the threads and subscriptions to set-up.

The subscriptions are set-up to any controls that emit signals where the subscribers are slots defined in JavaScript. Forms are defined in XML and there are currently three add ons I've already developed to give low level File I/O access, XML access and Database access. Additional modules are easy to add.

In my example form I have an instance of QListWidget that allows a selection of an individual which is populated from a database table. When a selection is made the fields associated with the selection are populated in the forum. If the user changes any of the control contents and then changes the selection before confirm I want to prompt the user for confirmation. This is all going to be configurable in the XML and script.

I believe now I have all the information to complete this. Thank you for your help.

SPlatten

@VRonin , the only problem I've found so far is the order in which the signals are emitted, the list widget signals are emitted before the model selectionChanged signal.

VRonin

Ok, the problem can be solved with a simple reimplementation of the selection model:

#include <QItemSelectionModel>
class AskSelectionModel : public QItemSelectionModel{
    Q_OBJECT
    Q_DISABLE_COPY_MOVE(AskSelectionModel)
public:
    using QItemSelectionModel::QItemSelectionModel;
public slots:
    void select(const QItemSelection &selection, QItemSelectionModel::SelectionFlags command) override{
        askSelect(selection,command);
    }
    virtual void actuallySelect(const QItemSelection &selection, QItemSelectionModel::SelectionFlags command){
        QItemSelectionModel::select(selection,command);
    }
signals:
    void askSelect(const QItemSelection &selection, QItemSelectionModel::SelectionFlags command);
};

int main(int argc, char *argv[])
{
   QApplication app(argc,argv);
   QListWidget mainWid;
   AskSelectionModel* askModel = new AskSelectionModel(mainWid.model(),&mainWid);
   mainWid.setSelectionMode(QAbstractItemView::ExtendedSelection);
   mainWid.setSelectionModel(askModel);
   for(int i=0;i<5;++i)
       mainWid.addItem(QStringLiteral("Item ") + QString::number(i));
   QObject::connect(askModel,&AskSelectionModel::askSelect,[&mainWid,askModel](const QItemSelection &selection, QItemSelectionModel::SelectionFlags command){
       if(QMessageBox::question(&mainWid,QStringLiteral("Are you sure?"),QStringLiteral("Are you sure you want to change the selection?")) == QMessageBox::StandardButton::Yes){
           askModel->actuallySelect(selection, command);
       }
   });
   mainWid.show();
   return app.exec();
}

SPlatten

Thank you, I've now re-designed my GUI interface and now its much simpler and doesn't require any manipulation of the model.

SPlatten

@VRonin said in QListWidget, how to post a question to the user before allowing change?:

QItemSelectionModel
I know this is quite old now, I'm looking at implementing this now, in the slot:

void select(const QItemSelection &selection, QItemSelectionModel::SelectionFlags command) override{
        askSelect(selection,command);
    }

Is the line askSelect correct? because its a signal in the class, shouldn't it read:

emit askSelect(selection, command);

?

jsulm

@SPlatten You don't have to use emit.
emit is an empty macro and is only used to make clear to the reader of the code that a signal is emitted.
Also, trying to execute the code is faster than asking in a forum and waiting for an answer :-)

J.Hilk

@SPlatten emit ist syntactic sugar, it expands to void. askSelect is a simple function, that has it function body in the *moc file that qmake creates.

but, yes you can add it :D

SPlatten

@VRonin , can you help with this implementation?

//ABC = Ask Before Change
QString strABC(mpobjNode->strGetAttribute
                                (clsXMLnode::mscszAttrAskBeforeChange));
if ( strABC.isEmpty() != true ) {
//Use "clsQtAskBeforeChange" to prompt user for confirmation if
//changes in child nodes before allowing change
    clsQtAskBeforeChange* pobjABC(new clsQtAskBeforeChange(model(), this));
    setSelectionMode(QAbstractItemView::ExtendedSelection);
    setSelectionModel(pobjABC);
//Now the widget should be set-up, finalise set-up
    clsXMLinterface::setup();
//Connect signal
    clsQtListWidget* pobjThis(this);
    QObject::connect(pobjABC, &clsQtAskBeforeChange::pendingSelect
                ,[pobjABC, strABC, pobjThis](const QItemSelection& crobjSelection
                    ,QItemSelectionModel::SelectionFlags cmdFlags) {
        if ( QMessageBox::question(pobjThis, QStringLiteral("Please confirm...")
                , strABC) == QMessageBox::StandardButton::Yes) {
            pobjABC->actuallySelect(crobjSelection, cmdFlags);
        }
    });
}

The above is in my implementation of QListWidget constructor. On the line that contains:

QObject::connect(pobjABC, &clsQtAskBeforeChange::pendingSelect

To the right of it I have the message:

Pass a context object as 3rd connect parameter [clazy-connect-3arg-lambda]

This is cryptic, I don't understand what it is telling me, have I done anything wrong because the code seems to work fine?

JonB

@SPlatten
Although this 3-argument connect() works, it is more usual to pass 4 arguments, with the 3rd argument being the "context" object for the slot's this. That is what the warning is telling you. I believe you can get rid of that via (something like):

    QObject::connect(pobjABC, &clsQtAskBeforeChange::pendingSelect
                , pobjABC, [strABC, pobjThis](const QItemSelection& crobjSelection
                    ,QItemSelectionModel::SelectionFlags cmdFlags) {
        if ( QMessageBox::question(pobjThis, QStringLiteral("Please confirm...")
                , strABC) == QMessageBox::StandardButton::Yes) {
            this->actuallySelect(crobjSelection, cmdFlags);
        }
    });

Christian Ehrlicher

@JonB Since the lambda accesses this, the third parameter should be this too. Otherwise the disconnect will not be done when this is deleted but pobjABC is still alive.

JonB

@Christian-Ehrlicher
I'm lost --- where does the (original) lambda access this? The only this is the one I put in for the pobjABC which I have made the context? In the body I replaced pobjABC->actuallySelect() by this->actuallySelect(), for clarity; and I chose pobjABC as the context as it felt like that was the primary slot object there. (I did get this right, didn't I? The slot-context-object, my pobjABC, becomes this in the lambda body?) My thought was to pass that as it won't be disconnected if pobjABC dies. I admit I didn't look terribly closely, I get awfully mixed with all the OP's pobj...s :)

Christian Ehrlicher

@JonB I only looked at your answer - the slot accesses this and not pobjABC so the signals scope should be this too :)

SPlatten

@JonB , pobjABC does become this in the lambda because the connection is created using pobjABC.

I've tried various suggestions, however I'm still getting the same result:

Pass a context object or 3rd connect parameter [clazy-connect-3ard-lambda]

This is gibberish because there are already 3 parameters passed. I even changed the parameters to:

[strABC, pobjABC, this, pobjThis]

Still get the same message.

Christian Ehrlicher

@SPlatten said in QListWidget, how to post a question to the user before allowing change?:

This is gibberish because there are already 3 parameters passed.

This is not gibberish - you only have to read it properly and our answers... you have to pass a context as third parameter, not the lambda (this should be the forth then)

JonB

@SPlatten
I posted mine with a 4th parameter and explained. Did you actually copy it and get the same error message? I don't think so. The issue is the number of parameters to connect(). You are looking at the number of items in the [...] context for the lambda, which is not what the message refers to.

SPlatten

@JonB , @Christian-Ehrlicher , sorry, it wasn't clear to me at first that the actual 3rd parameter you were referring to was of the connect, I thought it was the 3rd parameter of the lambda set.

It was more confusing because when compiled the connect worked without the 3rd parameter. being correct.

JonB

@SPlatten
Your 3-parameter one should work, the [clazy-connect-3arg-lambda] should be a warning that it can be inadvisable because of lifetime/disconnect behaviour.