Как установить курсор в QLineEdit в начало текста?

[radislav72]

Идея такая: если на QLineEdit установлена маска (inputMask), то при клике мышью на виджете с целью ввода текста курсор ставится в позицию клика, даже если текст еще не введен вообще и виджет "пустой". Так что пользователю, чтобы начать вводить значение, нужно сделать еще одно лишнее движение: жать Home перед вводом.

Как попроще обойти такое поведение? То есть, можно при FocusIn проверять наличие маски и принадлежность классу QLineEdit и поставить курсор в начало, если текст пустой.

Но как переместить курсор в QLineEdit?

[Prm]

void setCursorPosition(int pos);

[radislav72]

 
Спасибо!

Я уже сильно усложнил все, старался сделать по аналогии с QTextEdit.

[radislav72]

Правда, моя радость была преждевременна

По нажатию отдельной кнопке все работает. Но в контексте нужного поведения QLineEdit- проблема. Делаю так:

Код:

bool mem_new_phpDialog::eventFilter(QObject *o, QEvent *e)
{
    if (e->type() == QEvent::FocusIn)
    {
        if (o->metaObject()->className() == QLatin1String("QLineEdit"))
        {
            if (qobject_cast<QLineEdit*>(o)->inputMask() != "")
            {
                qobject_cast<QLineEdit*>(o)->setCursorPosition(0);
            }
        }
    }
    return QDialog::eventFilter(o, e);
}

Код выполняется, но при вызове обработчика по умолчанию он перекрывает нужное поведение и снова устанавливает курсор посредине QLineEdit-а. Если же сделать вместо вызова обработчика по умолчанию return true, поведение QLineEdit вообще странное: иногда курсор действительно переходит в начало, иногда (чаще) нет, а сам курсор вообще не мигает...

Как все ето можно обойти?

[ритт]

> Если же сделать вместо вызова обработчика по умолчанию return true, поведение QLineEdit вообще странное...
переведу:
Если же вместо вызова обработчика херить все события, отправляемые некоему QLineEdit, поведение данного QLineEdit вообще странное...

читайте внимательно документацию по QEvent и eventFilter()

[radislav72]

Поиски в Гугле вроде дают результат, свидетельствующий о какой-то проблеме при связке QLineEdit, FocusIn и setCursorPosition (например QLineEdit setCursorPosition & cursor blinking problems).

Ну я сделал по-другому: вместо FocusIn использовал MouseButtonPress, и вместо setCursorPosition просто выделяю весь текст LineEdit-а, если он пустой. При вводе не мешает.

[radislav72]

Если же вместо вызова обработчика херить все события...
...читайте внимательно документацию по QEvent и eventFilter()

Спасибо за ответ. Но я не совсем понял намека: в документации QT для QObject::eventFilter написано:

In your reimplementation of this function, if you want to filter the event out, i.e. stop it being handled further, return true; otherwise return false.

То-есть, если я хочу остановить последующую обработку сообщения, возвращаю true. Я думал (и думаю), что курсор переустанавливает обработчик сообщения по умолчанию, потому хотел его "обойти" и вызывал true. Может, я не правильно понимаю, но в той же документации QT есть пример:

Код:

if (event->type() == QEvent::KeyPress) {
             QKeyEvent *keyEvent = static_cast<QKeyEvent*>(event);
             qDebug() << "Ate key press" << keyEvent->key();
             return true;
         } else {
             return false;
         }

То есть действительно возвращают просто true. В чем заключается "похерение всех событий"?

[Marat(Qt)]

Если же вместо вызова обработчика херить все события...
...читайте внимательно документацию по QEvent и eventFilter()

Спасибо за ответ. Но я не совсем понял намека: в документации QT для QObject::eventFilter написано:

In your reimplementation of this function, if you want to filter the event out, i.e. stop it being handled further, return true; otherwise return false.

То-есть, если я хочу остановить последующую обработку сообщения, возвращаю true. Я думал (и думаю), что курсор переустанавливает обработчик сообщения по умолчанию, потому хотел его "обойти" и вызывал true. Может, я не правильно понимаю, но в той же документации QT есть пример:

Код:

if (event->type() == QEvent::KeyPress) {
             QKeyEvent *keyEvent = static_cast<QKeyEvent*>(event);
             qDebug() << "Ate key press" << keyEvent->key();
             return true;
         } else {
             return false;
         }

То есть действительно возвращают просто true. В чем заключается "похерение всех событий"?

Видимо имелось ввиду это:

Код:

bool mem_new_phpDialog::eventFilter(QObject *o, QEvent *e)
{
    if (e->type() == QEvent::FocusIn)
    {
        if (o->metaObject()->className() == QLatin1String("QLineEdit"))
        {
            if (qobject_cast<QLineEdit*>(o)->inputMask() != "")
            {
                qobject_cast<QLineEdit*>(o)->setCursorPosition(0);
                return true;
            }
        }
    }
    return QDialog::eventFilter(o, e);// если поставить здесь return true - то все объекты для которых включен
                                                // eventfilter перестанут реагировать на события (кроме, конечно, lineedit'a с маской)
}

Кстати глубокого смысла строки "return QDialog::eventFilter(o, e);" я так и не уловил

[radislav72]

Видимо имелось ввиду это...

Я как раз так и делал. И такой код не приводит к желаемому: т.е. курсор НЕ устанавливается в начало, если все ето делается в обработке события FocusIn. Если вызвать установку курсора, например, при нажатии какой-то кнопки, то все работает хорошо, а из eventFilter- нет. В том весь мой вопрос и заключался.

Если в приведенном Вами коде сработает строка return true; (та, что после setCursorPosition), то return QDialog::eventFilter(o, e); уже, соответственно, никогда не выполнится, потому я и писал, что вместо стандартного обработчика вызывал return true. Правда, допускаю, что я не совсем правильно выразился в етом месте.

Полностью заменять QDialog::eventFilter на return true я не собирался

Фактом остается то, что приведенный мной (и повторенный Вами) код не устанавливает курсор в начало строки.