How to popup a message box when QAbstractModel::setData got invalid data?

[jsulm]

@jronald said in How to popup a message box when QAbstractModel::setData got invalid data?:

For example, a cell is for string whose length should be from 3 to 10.

User input validation should b e done in the UI.
See https://doc.qt.io/qt-5/qvalidator.html - there are several derived classes.

[jronald]

@jsulm said in How to popup a message box when QAbstractModel::setData got invalid data?:

User input validation should b e done in the UI.

Yes, but where to put the code that pops up the message box?

[artwaw]

@jronald As I mentioned, independently of how you act on the return value (@JonB and @jsulm raised absolutely valid points) you can just emit a signal (you'd need to define it the class that handles setData()) and connect it to the slot defined wherever it suits you (class holding the window with the view/main class/wherever convenient and possible).

[jronald]

@artwaw

Anyway to implement the procedure as below:

1. User input invalid data and press "Enter"
2. Message box popups to tells the user what's wrong
3. Close the message box, the editor should not be closed and setData has not been called yet, the user can continue the editing before the message box

[JonB]

@jronald
Respectfully, I am going to disagree with my learned colleague @artwaw here. As i said earlier, I do not see this as a signal situation. setData() returns immediately from wheberever it is called from with a return result, and calling code continues immediately after this. We don't know what that might do. At some (potentially) later point a signal arrives stating there was an error. At which point you suddenly show the user a message.

Where are you calling the setData() from? Somewhere in the UI? In that case why not get whatever information you need directly (on the next line of code after calling setData()) and display the message there and then?

[artwaw]

@JonB said in How to popup a message box when QAbstractModel::setData got invalid data?:

Respectfully, I am going to disagree with my learned colleague @artwaw here.

I agree you know better! No doubts in that. But I think I also see the use case the OP tries to achieve.

The flow I had in mind was more along the lines:

if (!model.setData()) {
emit presentUserWithDialog();
}

This can be implemented together without breaking stuff, doesn't it? Sorry if that was not clear earlier.
I might be, of course, wrong - would not be the first time.

[JonB]

@artwaw said in How to popup a message box when QAbstractModel::setData got invalid data?:

I agree you know better!

I would never assume that :)

if (!model.setData()) {
emit presentUserWithDialog();
}

OK, this is better. I had understood you to be following @jronald's proposed path where it would the setData() implementation itself which emitted the signal. Now that I see you have the caller checking the result from setData() and doing the emit I am much happier.

Whether that caller is then better emitting a signal or (if it is a UI caller) just doing the message itself there & then is a smaller matter.

[SGaist]

Hi,

@jronald said in How to popup a message box when QAbstractModel::setData got invalid data?:

1. User input invalid data and press "Enter"

"Enter" shall not be enabled as long as the input data is invalid.

No need for a message box.

[jronald]

@SGaist said in How to popup a message box when QAbstractModel::setData got invalid data?:

"Enter" shall not be enabled as long as the input data is invalid.

How to disable "Enter" conditionally?

@SGaist said in How to popup a message box when QAbstractModel::setData got invalid data?:

No need for a message box.

A message box can tell the user what's wrong, it is helpful.

[SGaist]

@jronald said in How to popup a message box when QAbstractModel::setData got invalid data?:

How to disable "Enter" conditionally?

Tie it to a validator's validity state.

@jronald said in How to popup a message box when QAbstractModel::setData got invalid data?:

A message box can tell the user what's wrong, it is helpful.

A UI that is explicit with regard to what it expects is better.

Do you really like to enter information in an application to just to have a message tell you that you have to do it all over again because of various constraints ?
Constraints that are usually lost as you need to close the dialog to access the UI again ?

Make things simple and clear:

• If you need a number in a range use a QSpinBox
• If you need a line of text with requirements use a QLineEdit with a suitable validator.
  Add an icon beside it with a QToolTip giving the expected input or a label underneath it with that advice.