[SOLVED] QLineEdit does not receive character input on Android

SteveMBay

Hello!

Today's strange question: I have added two simple QLIneEdit to my dialog, but I can't edit them. I got the cursor, I can type, but nothing happens.

I thought that my some additional property causing this. I have found a working QLineEdit in my application, but for first look I cant spot any difference.

Yes, I disabled it at construction, but the problem occurs after I enabled it later.

I am testing my application on an Acer Iconiatab A700 with default Android and with other virtual keyboards, but nothing. I can type, the suggestion above the chars are there, but the input filed remains empty.

ui_mydialog.h

    QLineEdit *authorName;
    authorName = new QLineEdit(MctMainDialog);
    authorName->setObjectName(QStringLiteral("authorName"));
    authorName->setEnabled(false); // but later I enable it
    verticalLayout->addWidget(authorName);

ui_workingtext.h

    QLineEdit *fileNameLineEdit;
    fileNameLineEdit = new QLineEdit(SaveAsDialog);
    fileNameLineEdit->setObjectName(QStringLiteral("fileNameLineEdit"));
    horizontalLayout_2->addWidget(fileNameLineEdit);

tarod.net

@SteveMBay Difficult to say with the sample code you provided.

Have you tried to comment the line

authorName->setEnabled(false); // but later I enable it

and checked if the wrong behaviour is still present?

SteveMBay

@tarod.net Yes, I tried, but its behave the same way.

What other Qt part could influence the behavior of the QEditLine?

tarod.net

@SteveMBay Maybe the problem is your dialog window.

Try to activate the dialog using something like this:

// virtual override
void MctMainDialog::showEvent( QShowEvent* showEvent )
{
    QDialog::showEvent( showEvent);
    activateWindow();
}

SteveMBay

@tarod.net Okay, I'll give a try. But I have buttons for example on my dialog and they are doing fine.

tarod.net

@SteveMBay I'm curious. Why are you using a QDialog instead of a QWidget?

Usually, a dialog window is a top-level window for short-term tasks and brief communications with the user.

I've found a post which can be useful to you:

http://stackoverflow.com/questions/2180070/qdialog-doesnt-accept-text-input-if-modal

SteveMBay

@tarod.net Nice catch! But I am using show() and have the problem.

About QWidget, I have a menu handler class which has more widgets and dialogs as well. I choose dialog because its a communication interface between the app end the user. Anyway, a dialog should be able to handle text input proper.
But I am new in Qt, so I could be wrong :)

tarod.net

@SteveMBay Mmm. It's difficult to give you more help. Could you please show more code? I think the problem is the window or dialog which is displaying authorName.

Also, you could try to change the QDialog and use a QWidget instead, only to check the difference.

SteveMBay

@tarod.net Hmm... I am thinkg about what if previously a slot was created for text change event, but already its removed.

Is it possibble that some artifact remained somewhere that actually occure when the text changed but does nothing?

tarod.net

@SteveMBay Well, if you connect a slot to the signal textChanged(const QString & text), do you receive data in that slot?

SteveMBay

@tarod.net I tried all the suggestions without success...

QWidget works the same
textEdited() and textChanged() slots never called

So here are some snipplets from this class.

myDialog.h

class MctMainDialog : public QWidget
{
 Q_OBJECT
 public:
 explicit MctMainDialog(QWidget *parent , KWDocument *document , QString url);
 ~MctMainDialog();
 public slot: // some button action 
 private: // some custom private action
 }

myDialog.cpp : constructor

MyDialog::MyDialog(QWidget *parent, KWDocument *document, QString url) :
        QWidget(parent),
        ui(new Ui::MctMainDialog),
        document(document),
        fileUrl(url),
        isEnabled(false)
    {
        ui->setupUi(this);
        this->setWindowFlags(Qt::Popup| Qt::FramelessWindowHint);
        sc = QApplication::primaryScreen();
        sc->setOrientationUpdateMask(Qt::LandscapeOrientation | Qt::PortraitOrientation | Qt::InvertedPortraitOrientation | Qt::InvertedLandscapeOrientation);

        connect(sc, SIGNAL(orientationChanged(Qt::ScreenOrientation)), this, SLOT(orientationChanged(Qt::ScreenOrientation)));
        connect(this, SIGNAL(start()), this, SLOT(startFunctionality()));
        connect(this, SIGNAL(openMManager()), this, SLOT(mManager()));
        connect(this, SIGNAL(openRManager()), this, SLOT(rManager()));        
        connect(this, SIGNAL(clearComboBox()), ui->revComboBox, SLOT(clear()));

        ui->currentRevNumLabel->setText("0");
    }

I am not sure what other part of my code would be interresting. I call the constructor once in a handler class, than connect some signals and slots and thats all. Buttons, ComboBox, other signals/slots doing fine.

Hmm.. and from the ui code:

  <widget class="QLineEdit" name="authorName">
   <property name="enabled">
    <bool>false</bool> <!-- This is the initial case, re-enabled after some action -->
   </property>
   <property name="text">
    <string/>
   </property>
   <property name="placeholderText">
    <string>Author</string>
   </property>
  </widget>

tarod.net

@SteveMBay Hi Steve,

I don't see where you are enabling authorName. When and where is the property changed?

BTW, I see the code isEnabled(false) in your constructor. Do you want to disable the window at the beginning?

SteveMBay

@tarod.net
I have a private method to enable/disable the ui elements when the functionality is turned on. There will be the authorName enabled as well. And yes, at the beginning all ui elements of this dialog are disabled.

Fortunately I managed to fix it. You had almost right, inheriting from QWidget is the solution.
(Also, here is a related stack overflow question without answer.)

But I created the interface with Qt Creator and tried to manually change the base class. Unsuccessful.
I had a liitle time today, so recreated the entire UI in Qt Creator using QWidget, and taa-daa, it works now.

So, thanks for the advices!

tarod.net

@SteveMBay Great, Steve! Good work.

It was a pleasure talking with you.

SteveMBay

Oh, and wait a sec...
I forgot to add the following line:

this->setWindowFlags(Qt::Popup| Qt::FramelessWindowHint);

It was neccessary becasue without it I was not able to hide my widget when other parts got focus.
But after I added it, the line edit went awry again...
I am so confused now...

tarod.net

@SteveMBay I don't understand why you need that flags. With those flags, you get a window modal and with no frame, but you are not hiding the window, aren't you?

Anyway, I know there are people complaining about that issue on the Internet.

http://stackoverflow.com/questions/7654422/no-keyboard-input-if-qlineedit-on-frameless-popup-window

https://forum.qt.io/topic/10115/no-keyboard-input-if-qlineedit-on-frameless-popup-window/3

http://www.qtcentre.org/threads/48401-QLineEdit-is-not-Editable-in-a-widget-with-X11BypassWindowManagerHint-flag

http://stackoverflow.com/questions/2180070/qdialog-doesnt-accept-text-input-if-modal

Try with setWindowFlags(Qt::X11BypassWindowManagerHint | Qt::Popup);

SteveMBay

@tarod.net Definitely, I have the same issue. At the beginning I did not know that was caused by the flags.
I tried your suggestion - and also called activateWindow() right after using show() - but still no input operation.

If I dont use the flags the widget wont disappear after I touch the surrounding area.

tarod.net

@SteveMBay Which flag is the "bad guy" here? Qt::Popup or Qt::FramelessWindowHint?

SteveMBay

@tarod.net I just wanted to write. :) It isn't a "back & white" situation.

Qt::Popup is the "bad" who prevents to use the QLineEdit but it is the "good" as well, because it allows the background to get input (and this hides my widget). As I've read in the Qt doc other flags prevent the background to get any input.

tarod.net

@SteveMBay Sorry, Steve, but I don't understand well the situation.

When you say "background", you mean another window which is showing your MctMainDialog class?
The widget you mention, is the MctMainDialog class you showed some days ago?
You say the widget won't disappear after you touch the surrounding area, but if you detect a touching event, you could hide the widget or window using the functions provided by Qt, couldn't you?