[Solved] How to subclass QLineEdit



  • Hi All,

    I would like to Subclass QLineEdit so that it has a signal that returns a pointer to the QLineEdit itself.

    I have a lot of QLineEdit that are connected using a loop. However, right now I am using a signalMapper to pass the QLineEdit ID to a slot. Using a direct pointer would be a lot easier and cleaner and provide easy access to all class.

    Could you help me build a simple implementation of that?


  • Moderators

    and about which signal you are talking about?



  • I would build MyLineEdit class

    @#ifndef MYLINEEDIT_H
    #define MYLINEEDIT_H

    #include <QWidget>
    #include <QLineEdit>

    class MyLineEdit : public QLineEdit
    {
    Q_OBJECT
    public:
    explicit MyLineEdit(const QString & contents, QWidget * parent = 0);

    signals:
    void output( QLineEdit* currentLineEdit);

    public slots:
    void textChanged(const QString & contents);

    };

    #endif // MYLINEEDIT_H
    @

    @#include "mylineedit.h"

    MyLineEdit::MyLineEdit(const QString &contents, QWidget *parent) :
    QLineEdit(parent)
    {
    unsigned int test;
    test=1;
    }

    void MyLineEdit::textChanged(const QString &contents){
    emit output( CurrentLineEdit );
    }

    @

    The question would bo how to get the CurrentLineEdit pointer from the class itself.. I don't think it is possible is it?



  • bq.
    I would like to Subclass QLineEdit so that it has a signal that returns a pointer to the QLineEdit itself.

    the signal's receiver always can get the sender as QObject*, so I think no need for such signal


  • Moderators

    you are thinking to complicated ;)

    Is something like this what you want?
    @
    class MyLineEdit : public QLineEdit
    {
    Q_OBJECT
    public:
    explicit MyLineEdit(const QString & contents, QWidget * parent = 0);

    signals:
    void textChanged( QLineEdit*, cosnt QString &);

    protected slots:
    void onTextChanged(const QString & contents);
    };
    @

    @
    MyLineEdit::MyLineEdit(const QString &contents, QWidget *parent) :
    QLineEdit(parent)
    {
    connect(this SIGNAL(textChanged(const QString &)), this, SLOT(onTextChanged(const QString &)));
    }

    void MyLineEdit::onTextChanged(const QString &contents)
    {
    emit textChanged( this, contents );
    }
    @


  • Moderators

    [quote author="NicuPopescu" date="1381493320"]
    the signal's receiver always can get the sender as QObject*, so I think no need for such signal[/quote]
    i would avoid using sender() in any case, since it breaks OOP concept and you also can't use it in queued connections.



  • Yes... by passing this.. you are passing the current object. Nice!

    However, you define @void textChanged( QLineEdit*, cosnt QString &);@

    with 2 arguments and you connect only the QString??



  • ok.. so the correct way to do it would be to get the sender QObject pointer instead. I will look into that.

    Thanks



  • bq. and you also can’t use it in queued connections

    have you tested?

    bq. Qt::AutoConnection 0 (default) If the signal is emitted from a different thread than the receiving object, the signal is queued, behaving as Qt::QueuedConnection. Otherwise, the slot is invoked directly, behaving as Qt::DirectConnection. The type of connection is determined when the signal is emitted.

    bq. Warning: As mentioned above, the return value of this function is not valid when the slot is called via a Qt::DirectConnection from a thread different from this object's thread. Do not use this function in this type of scenario.

    so, as far as I understand with Qt::AutoConnection always will work ... is there a warning for using from a different thread with Qt::DirectConnection, which is not default ...


  • Moderators

    [quote author="bareil76" date="1381493753"]
    However, you define @void textChanged( QLineEdit*, cosnt QString &);@
    with 2 arguments and you connect only the QString??[/quote]
    Yes i define the textChanged signal with 2 arguments. The one with 1 argument is still available from the QLineEdit base class. Thus it's a different signal, since the signature is different.

    [quote author="NicuPopescu" date="1381494337"]
    have you tested?[/quote]
    you can do it if you don't believe it ;)
    I know that it won't work.
    In the queued connection an event - containing the parameters as copy - is generated which calls the slot. So there definitely happens a decoupling of the sender.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.