Question

I’m usually used to the .net framework and recently got the chance to work on a project using C++/Qt. In this context, I want to implement the following functionality: (to simplify things lets say I have a ListView and a Textbox/Textedit)

• If I select an item of the ListView -> show the corresponding text in the textedit (done)
• If I edit the text and click on another item in the list -> show a dialog that asks whether to save or cancel the changes (done). The textedit gets a signal from the list telling it that the selected item has changed.
• If the user presses save -> save it back and refresh the item in the list, the new item which the user clicked gets selected in the list (done)
• If the user presses cancel -> don’t select the other item which the user clicked (this is where my problem is)

Basically I see two solutions (there may be more) to this:

• Send a signal back from the textedit to the list, telling the list to restore the previous selection. I personally dont like this solution very much, because I have to couple them stronger (the list sends signals to the textedit and now also the other way around). Also, this ‘forced’ selection restoration could again trigger subsequent signals that would have to be blocked again…
• A much nicer solution (I think) would be to have some Veto-mechanism in the signals. I could imagine the list to send two signals:
  • lets call the first one aboutToChangeSelection(proposedSelection, vetoObj)
  • and another one after the action is done: changedSelection(newSelection)

The first signal would be sent to the textedit, which would then eventually make use of its veto. After this, the same signal would be sent to the list itself, do the action depending of the veto and send the second signal if it actually changed the selection.

In the .NET world there exists such a mechanism, with the help of CancelEventArgs. I know that .NET events and Qt signals have quite a different working principle, but is there any Qt equivalent to archieve the same effect?

Thanks a lot for any help!

Answer 1

If you are using a QListWidget instead of a QListView, then you can do the following:

• listen to the signal : QListWidget::itemPressed ( QListWidgetItem * item ) rather than the signal saying the item has changed (ie currentItemChanged ( QListWidgetItem * current, QListWidgetItem * previous ) in my example )
• The function which opens the dialog is a slot connected to this signal. I don’t think it need to be modified.
• Listen to the signal : currentItemChanged ( QListWidgetItem * current, QListWidgetItem * previous ) which will be used only to remember the current and last item.
• Now in your case, when the user set cancel, programmatically change back to the last item.

Now there is one problem. Which signal will be received first?? Not specified in the doc, and it can be in any order. If a user is on item A, and clicks on item B, you want lastitem to be A, and current item to be B at the moment you are handling itemPressed. So you want to handle currentItemChanged first. Fortunately you can do use Qt::DirectConnection for currentItemChanged and use Qt::QueuedConnection for itemPressed

ALTERNATIVE:

You can use an event filter on the list widget. This filter will be the one to perform the processing you described in your few steps. If the user clicks accepts, you send the event to the list view. If the user reject, you block the event. I am not sure, but it is possible that the events are not processed in a filter which will make this alternative non-viable.