creating list with variable number of entries

[mzimmers]

@SGaist so, I subclass QItemDelegate and override the createEditor() method? What do I specify as the model?

Thanks...

[SGaist]

No, QStyledItemDelegate.

The item delegate is applied on the view.

[mzimmers]

@SGaist OK, I looked at the StarDelegate example. I don't really know what I'm doing, but I created this:

class ICdelegate : public QStyledItemDelegate
{
    Q_OBJECT
private:
public:
    QLineEdit *createEditor(QWidget *parent, const QStyleOptionViewItem &option,
                          const QModelIndex &index) const override
    {
        static QLineEdit qle;
        const IpValidator *ipValidator;
        qle.setValidator(ipValidator);

        return const_cast<QLineEdit *>(&qle);
    }
};

I get a segfault on the call to setValidator(). I'm sure I'm overlooking something obvious (I know I'm not using any of the arguments passed to the function), but I can't see what it is.

Thanks...

[jsulm]

@mzimmers said in creating list with variable number of entries:

I get a segfault on the call to setValidator()

Of course you do as you're passing a dangling pointer - your ipValidator is not pointing to an IpValidator instance.

[mrjj]

Hi

 QLineEdit *createEditor(QWidget *parent, const QStyleOptionViewItem &option,
                          const QModelIndex &index) const override
    {
        static QLineEdit qle; // not good idea as i think its deleted for you.. so new it
        const IpValidator *ipValidator; // this needs to be newed too
        qle.setValidator(ipValidator);

        return const_cast<QLineEdit *>(&qle);
    }

[mzimmers]

@mrjj do I correctly understand that using "new" to create Qt objects here, without a corresponding "delete," will not cause a memory leak?

In any event, I made the fixes suggested, and the program runs now. A couple of issues remain, though:

1. the QLineEdit shows up in its own window
2. the widget from which the QLineEdit is created retains control (I can't access the QLineEdit window until the main widget is closed). I'm guessing I can fix this with a call to activateWindow(), but I really don't want a separate window for this edit in the first place. I was hoping for "in-place" editing -- is this possible with a QListWidget?

Thanks for the help.

[mrjj]

@mzimmers

Hi , yes normally a new without delete is a leak but the design for the delegate is that you create editor and
the View deletes it when finished editing.

1. you dont assign the parent when you new it
   QLineEdit *ql = new QLineEdit(parent)
   Any widget without a parent becomes a window.

2. fix 1 and 2 is non issue i think :)

[mzimmers]

@mrjj Oh, that's a thing of beauty. Thanks for the reminder on that.

And you're correct, adding the parent to the creation of the QLineEdit eliminated the new window.

This issue is mostly fixed now, but there's still a bit of tuning I need to do:

1. When editing a line, pressing the enter key exits the window. This is logical, but probably not what a lot of users expect. I need to cause it to exit the editor (I think). I think I could fix this by overriding the EditorEvent() method, but I don't know what I'd furnish for the model argument.
2. It appears that the editor also remains open when the user clicks on a different line. Basically, the same issue as above (I think).

Thanks again...

[mrjj]

@mzimmers
Hi
I don't recall pressing enter would do anything but finish editing so not sure all code is as it should be.
Can you check your code against
https://stackoverflow.com/questions/26614678/validating-user-input-in-a-qtableview
As this is the same you want to do, using a Validator.
It don't matters its other type of view. The delegate is the same.

[mzimmers]

My code had some minor differences, but I changed them to match the example, and the behavior is the same.

I did realize something, though -- I still had my itemClicked() signal calling a slot that used openPersistentEditor(). I'm guessing that this wasn't what I wanted. But when I disabled this, I get no editor at all. Here's where I use the delegate:

    ICdelegate *icDelegate = new ICdelegate;
    ui->listWidgetServers->setItemDelegate(icDelegate);

Does this look OK to you?
EDIT:
PS: I didn't mention that I took SGaist's suggestion above to mean that the only method I overrode was createEditor() -- is this correct?
UPDATE:
here's my slot for when the item is double-clicked:

connect(ui->listWidgetServers, &QListWidget::itemDoubleClicked, this, &Informacast::editItem);
void Informacast::editItem(QListWidgetItem *item)
{
    Qt::ItemFlags flags;
    flags = item->flags();
    flags |= Qt::ItemIsEditable;
    item->setFlags(Qt::ItemIsEditable);
    ui->listWidgetServers->editItem(item);
}

Still not editable, though the coloring changes:

I feel that I'm close to getting this to work, but am overlooking something.

[SGaist]

AFAIR, items are editable by defaults.

Did you set the edit triggers ?

[mzimmers]

@SGaist I hate to disagree with you (mostly because you're always right), but here's my slot:

void Informacast::editItem(QListWidgetItem *item)
{
    Qt::ItemFlags flags;
    flags = item->flags();
    if ((flags & Qt::ItemIsEditable) == 0)
    {
        flags |= Qt::ItemIsEditable;
    }
    item->setFlags(Qt::ItemIsEditable);
    ui->listWidgetServers->setEditTriggers(QAbstractItemView::DoubleClicked);
    ui->listWidgetServers->editItem(item);
}

When I step through this in the debugger, I hit the line where I assign the editable flag.

To answer your question: no, I hadn't set the edit triggers. But now I am, and the behavior is still the same. In looking at the EditTrigger enums, I don't see another one that I need to set; am I overlooking something?

EDIT: from a debugging session, it appears that the DoubleClicked was already set.

[JonB]

@mzimmers said in creating list with variable number of entries:

item->setFlags(Qt::ItemIsEditable);

This resets all your flags, to editable only. Yet you earlier picked up the existing flags. I have a feeling you intended

item->setFlags(flags);

to enable editability? I have no idea whether this is relevant to your issue, it's just a code observation.

[mzimmers]

@JonB ding ding ding we have a winner! Good catch there. I was going to ask whether the setFlags worked that way, but I got distracted by all my other mistakes.

Now, the item is editable, but...my validator doesn't seem to be taking effect. I think I know why, but I'm not sure what to do about it. Here's my class:

class ICdelegate : public QStyledItemDelegate
{
    Q_OBJECT
private:
public:
    explicit ICdelegate(QObject *parent = nullptr) :
        QStyledItemDelegate(parent)
    {
    }
    QLineEdit *createEditor(QWidget *parent, const QStyleOptionViewItem &option,
                          const QModelIndex &index) const override
    {
        // some junk code to disable compiler warnings about unused variables.
        const QModelIndex xxx(index);
        if (xxx == index)
        {
            ;
        }
        const QStyleOptionViewItem yyy(option);

        QLineEdit *qle;
        qle = new QLineEdit(parent);
        qle->setValidator(new IpValidator);

        return (qle);
    }
};

Am I doing something wrong with qle? I tried making it a member variable, but got a compiler error.

Thanks...

[SGaist]

Try with:

qle->setValidator(new IpValidator(qle));

[mzimmers]

@SGaist another winner! The validator is now invoked. So, do I understand this to mean that the call to setValidator isn't sufficient to associate the QLineEdit with its validator; the validator uses its parent as the basis for what to operate on?

As a side benefit, pressing "enter" no longer dismisses the dialog. I think this problem is solved (but I'm not going to so mark it quite yet).

Thanks to everyone who helped with this.

[JonB]

@mzimmers
I'm waiting for The Master's answer on this too :) I looked up the docs and I do not see where it indicates this is required, and OK your validator may leak but I don't see it will die...