Суть проблемы:
Есть очень длинная форма для заполнения с QSpinBox, с QComboBox и т.п. Поскольку окно ограничено в размерах, то форма размещена на QScrollArea.
При кручении колёсика и прокрутке формы курсор мыши может оказаться на QSpinBox или QComboBox, и тогда их значения резко меняются.

Хочется, чтобы прокрутку формы можно было осуществлять только таская бегунок скроллера мышкой.
Пожалуйста, помогите реализовать. А то просто зашиваюсь по времени.
Если есть возможность "прихлопнуть" возможность изменения значений QSpinBox или QComboBox при вращении колёсика, такой вариант тоже сгодится. Может, такой вариант даже больше подойдёт.

Анна, прочитай описание
void QWidget::wheelEvent(QWheelEvent *event)

у тебя есть несколько вариантов:

1) для виджета scrollarea->widget запретить обработчик wheelEvent (тогда прокрутка будет возможна только ползунком)

2) для всех чайлдов scrollarea->widget поставить фильтр installEventFilter, а в eventFilter запрещать выполнение прокрутки чайлдов QEvent::Wheel. Тогда останется возможность всё крутить колесом, но контролы не будут дёргаться

3) самый сложный и самый "красивый" вариант: частично как №2 , но разрешать обработку прокрутки в чайлде, если на нём стоит фокус. Если же прокрутка производится не в чайлде, то фокус с чайлда убирать на scrollarea. Тогда чайлды будут иметь свою крутилку только тогда, когда по нему щёлкнули и сразу стали крутить колесо. Когда курсов уехал по scrollarea->widget, чайлдовая крутилка отключается

Спасибо.
Совсем забыла про installEventFiltr(). Берегитесь, спинбоксы!!!

Вообще, для меня QSpinBox, с одной стороны самый необходимый класс, но самый ненавидимый: либо предоставляет слишком много возможностей там, где мне не надо, либо не позволяет самых простых вещей. Например, мне нужно вводить в диапазоне для unsigned intили long long, и всё, приплыли.

Анна, где диапазон типа unsigned int или long long, там стрелки бесполезны, используй QLineEdit (опционально - с QRegExp валидатором)

я QSpinBox вообще не помню, чтобы пользовался. Самый бесполезный контрол, наверное )

Не скажите. Многие инженеры стрелочками спинбоксов пользуются, чтобы как на аппаратуре: сперва ввёл значение, а потом меняешь его с каким-то шагом.

Пришлось для long long написать. Это решило проблему unsigned int.

Не скажите. Многие инженеры стрелочками спинбоксов пользуются, чтобы как на аппаратуре: сперва ввёл значение, а потом меняешь его с каким-то шагом.

Пришлось для long long написать свой спинбокс. Это решило проблему unsigned int.

В общем, получился такой вариант:

bool MyWidget::eventFilter(QObject *target, QEvent *event)
{
    if(event->type() == QEvent::Wheel)
    {
        const char *className = target->metaObject()->className();
        if(QString(className) == QString("QComboBox"))
        {
             QCoreApplication::sendEvent(ui.scrollArea, event);
                         return true;
        }
        if(QString(className) == QString("QSpinBox") && !((QWidget*)target)->hasFocus() )
        {
            QCoreApplication::sendEvent(ui.scrollArea, event);
                        return true;
        }
    }
    return QWidget::eventFilter(target, event);
}

(Исправила немного, потому что в первом варианте фигня получилась. Так вроде бы правильно)

В конструкторе MyWidget у всех спинбоксов и комбобоксов вызываю installEventFilter(this), и устанавливаю StrongFocus.

В результате форма прокручивается, все спинбоксиы и комбрбоксы игнорируют вращение колеса, в спинбоксах колесо меняет значение только если кликнуть непосредственно в поле спинбокса и удерживать там мышку.

Осталось только выудить спинбоксы, которые размещены на других пользовательских виджетах в этой форме.

Анна,




накидал вот вариант обработчика. В аттаче файлы тестового диалога, создай диалог, чтобы посмотреть работу класса обработчика:

    MyWidget dlg(0);
    dlg.exec();

Нажмите для просмотра прикрепленного файла

Действительно. Я собиралась к этому куску вернуться. Уж как-то не рационально получалось. За имена классов зацепилась, потому что недавно пришлось их в лог выводить.
Правда, обычно я использую qobject_cast, но думаю, большой разницы нет.

......

do {} while(0);

Забавная конструкция! Никогда с такой не сталкивалась, но возможность использовать break; удобна. Про использование в макросах тоже почитала.

Анна,



то есть, если у класса есть виртуальные функции(а у всех наследников QObject они по определению есть), то стандартный dynamic_cast будет работать

я им обычно и пользуюсь

При таком варианте прокрутка "затыкается", как только мышка попадает на спинбокс или комбобокс.

Сделаю гибрид.
Правда, у меня есть подозрение, что в моём варианте не вё так просто с sendEvent(). Я считала, что этим вызовом передаю событие колеса, предназначенное дочернему виджету, в область прокрутки. Увы, в какой-то момент при закрытии окна иногда происходит обвал. Как я поняла - попытка удалить стековый экземпляр.

Анна, у меня вроде не затыкается, либо скажи, как в моём примере повторить баг, я попробую


а sendEvent в нашей задаче не нужен

посмотри описание eventFilter :

Алексей1153,
Я полностью тело функции к себе скопировала. Правда, у меня не диалог, а QSubWindow, а в нём куча виджетов, среди которых есть виджет, содержащий область прокрутки. Вот этому виджету я создала метод eventFilter()и его (виджет) передаю в installEventFilter() всем спинбоксам и комбобоксам.


Если я просто верну true,как в твоём примере, то событие от колеса не обработается не только спинбоксом, но и, вообще, кем-либо ещё (мне кажется, что "затык" как раз в этом месте и происходит). А мне нужно, чтобы оно обработалось, но не спинбоксом, а областью прокрутки.

Увы, но sendEvent() с принятым в eventFilter() событием, вызывает обвал или зависание при закрытии приложения.

а по теме - щас попробую описанный тобой случай воспроизвести у себя.


вот я добавил туда вложенный виджет класса QScrollArea. Обработчик даже не пришлось трогать, благодаря рекурсивному поиску чайлдов.

Нет никаких спонтанных зацеплений колеса за спины и комбы. Но если щёлкнуть по контролу - то колесо работает. То есть, всё как нужно

Давай тогда приложи свой пример, где проблема воспроизводится, я попробую поковырять

Увы, свой виджет дать не могу. У меня нет доступа в интернет с компа, но он не сильно отличается от первого варианта.

Вся печаль заключается в том, что когда я полностью подставила твой класс (правда, мой компилятор не всегда понимает твой код, пришлось подправить), то возникает проблема при закрытии приложения: либо приложение остаётся висеть в памяти (даже под отладчиком),, либо возникает ошибка "CRT detected that the application wrote to memory after end of heap buffer". Ошибка возникает только, если на виджете провернуть колесо. Это какой-то бред собачий. Но я под отладчиком виду как вызывается деструктор моего виджета, и дальше всё гибнет уже в глубинах куты.

У меня vc 2010.

В общем, стабильно работает вариант, когда eventFilter() является методом самого виджета, а вместо

return true;

стоит вызов

sendEvent(scrollArea->widget(),event)

Анна, Свой виджет давать не надо, просто накидай в новом проекте пример, где баги воспроизводятся. Тогда можно будет глянуть, что там


без рассмотрения кода ничего подсказать не смогу. Но точно уверен, что sendEvent там не нужен. Поймать краш тоже только в отладке смог бы, либо увидел бы, что ты что-то не так делаешь.

ну и интересно, что именно пришлось подправлять, там ты тоже могла допустить ошибки

Я скомпелила твой код. Прокручивается до тех пор, пока курсор мыши не наскочет на спинбокс или комбобокс. Если курсор мыши изначально находится на боксе (но у бокса фокуса нет), то кручение колеса не обрабатывается.

А что касается изменений, то пришлось убрать инициализацию
scrollArea =0
И цикл for(auto* child:list) заменила на обычный for(int i=0; i < list.count();i++) и в теле child на list.at(i).


Честно говоря, я не совсем понимаю, почему боксы, вообще, хватают фокус, когда крутится колесо, если у них установлен StrongFocus.

нельзя просто взять и убрать инициализацию, переноси в конструктор


- значит, для них не установлен фильтр. У меня всё работает, как задумано.

Поставь следующий эксперимент: для сообщения простого движения курсора (mouseMove) выведи в лог дебага какое-нибудь сообщение
qDebug()<<"..."

- порасставляй таких выводов повсюду, где нужно проследить поведение кода. Будешь шевелить мышкой и в реальном времени видеть, что куда летит

Она и так инициализируется в конструкторе. Ты же передашь туда указатель на QScrollArea.

С остальным попробую уже в понкдельник. Все Добби женского пола завтра свободны!

Одного жалко - столько времени на такую дребедень ушло. Утешает, что хоть что-то новенькое узнала, а то сплошная рутина: создай форму, выведи нанные в форме, получи данные из формы... И так десятки раз.

Анна, щас попробую с QMdiSubWindow пример нарисовать. Но быстро не получится, поэкспериментировать придётся )

кое-что исправил и упростил. В примере две кнопки - одна открывает прежний виджет, другая Mdi с четырьмя субокнами, в каждом из которых всё тот же виджет. Обработчик в обоих случаях один - универсальный

покрутил по всякому - вроде работает. Постарался без использования C++11 оформить. Если что будет непонятно - давай вопросы )

Нажмите для просмотра прикрепленного файла

Собрала твой пример. ...У меня, по-прежнему, прокрутка останавливается, как только курсор оказывается на любом боксе. Видимо, это реализация QT 5.5.1.

Попробую разобраться, почему некорректно завершается приложение, если всё-таки отдать событие области прокрутки через sendEvent(). Почему-то происходит попытка удалить статическую переменную. Я не вижу никакого "криминала" в том, что перехватив событие для бокса я отдаю его в обработку другому виджету. Видимо, какие-то тонкости я не учла. Если разберусь, остановлюсь на этом варианте.

Кстати, не вижу смысла устанавливать фокус на scrollArea->widget(). По-моему, предыдущий вариант со сбросом фокуса более приемлем.

Анна, у меня Qt 5.9.2, а на сайте уже аж 5.13

http://download.qt.io/development_releases/qt/

будет повод обновиться


насчёт фокуса - ну, надо куда-то его переставить, а просто убрать текущий не всегда возможно, ведь фоку может быть на чайлде другой области прокрутки

Анна, кстати, в описании сказано



а ты не создаёшь на стеке, а пересылаешь. Может, в этом проблема

Там в single исходники лежат?

Возможно, дело в относительных координатах, которые есть в событии. Попробую создать своё событие от колеса с правильными координатами.

не понимаю вопрос.
Я вообще вместе с QtCreator обычно обновляю, там в комплекте приложен Qt


сомневаюсь, что сдвинутые координаты могли вызвать краш

Ну... Сейчас QT хочет ставиться только онлайн. А у меня нет доступа в интернет с рабочей машины. Так что мне просто обновление не подходит. Надо будет ставить ручками. Кстати. 13 - это альфа версия. Официально в доступе для установки 12-я.


Увы. Я тоже в этом сомневаюсь. Если честно, я не понимаю, что такого криминального в том, что я перехватила событие, предназначенное для одного виджета, и передала на обработку в другой виджет. Да, при таком способе с относительными и глобальными координатами у события косяк, но не до такой же степени, чтобы давать повод обваливаться или зависать.

Есть тут на форуме один человек, который здорово помог когда-то с обработкой события закрытия. К сожалению, ника не помню. Аватарка - какой-то розовый пузатый покемончик. Я надеялась, что он заглянет сюда и что-нибудь дельное скажет.

Затыки прокрутки при попадании мышки на бокс решились просто:

if(!control->hasFocus())
{
event->ignore();
return true;
}

Об этом написано в документации к QWheelEvent.

А вот слёты при закрытии при приложения связаны с созданием екземпляра перехватчика события. Буду разбираться дальше.

Но изначальная проблема решена!
Спасибо, Алексей1153!

Анна, это ты про lanz'а, наверное, говоришь http://www.forum.crossplatform.ru/index.php?showuser=3660
- давненько не появляется почему-то. И вообще, я его сообщений как-то не нашёл, то ли он их поудалял все

насчёт краша - надо для начала ловить в отладчике, где остановилось, а там раскрутить стек обратно. Часто этого бывает достаточно для поиска проблемы

Если проблема связана со сроком жизни объекта, сделай его удаление явным (сейчас в его конструктор передаётся указатель на объект-парент, который вызывает delete своего чайлда в своём деструкторе). Например, в приватном мембере-указателе сохрани адрес фильтра-объекта, а в деструкторе вызови для него delete явно. Либо вообще попробуй вынести объект фильтра из "опекаемого" класса. Тогда экземпляр фильтра можно заставить жить дольше экземпляра "опекаемого" класса

Да, кажется, он.

Проблема решилась полной пересборкой. Похоже, я своими экспериментами довела msvc до ручки.

Ещё раз большое спасибо. Ты меня здорово выручил. Правда, я закомментила кусок со сбрасыванием фокуса с бокса. Бокс и так теряет фокус, если колесо крутится не на нём. И я сделала хандлер ребёнком от основного виджета.
Будет время, попробую сделать так, чтобы прокрутка срабатывала только при наезде мышки на вертикальный или горизонтальный скроллер,

кстати, да, такое тоже бывает. И не только у студии, но и у QtCreator тоже.

Если некоторое время какой-нибудь непонятный баг достаёт, рекомендую делать полный ребилд, а потом снова проверить наличие бага



пригодятся обработчики (либо фильтр на соответствующие события)

void QWidget::leaveEvent
void QWidget::enterEvent