Все достаточно просто. Есть поток в котором опрашиваются датчики. Состояние датчиков отображается на дисплее в виде квадратика с заливкой определенного цвета. Ну там красный цвет, датчик не исправный, зеленый исправен и т.д. Из потока передаю данные в виде массива. В массив загружаю данные состояния и адрес датчика. Вот этот массив нужно передать paintEvent.
Самый простой случай — у тебя есть класс, где данные рисуются, и класс, получающий информацию от датчиков. Тут просто заводишь поле в первом классе, делаешь слот-сеттер, который принимает массив по сигналу второго класса, ну а рисование делаешь уже через член класса, не думая о втором классе.
Если делать более правильно, то у тебя должен быть отдельно класс, отображающий квадрат правильного цвета (типа, класс отображения датчика), отдельно класс, раскидывающий множество классов отображения датчика по какой-то сетке. В первом классе делаешь сеттер исправен/неисправен, принимать должен тип bool. Во втором принимаешь данные от датчиков и дёргаешь вышеупомянутый сеттер. По идее, тебе даже paintEvent() переопределять так не придётся, поскольку в качестве первого класса можно использовать какой-нибудь QLabel. Реализация первого класса будет выглядеть как-то так:
короче, шлешь сигнал с инфой о датчиках в класс, который дергает перерисовку, если необходимо и состояние изменилось, вот тех лейблов что показали выше.
Очень простое решение. Создаешь глобальный массив int. Старший бит - признак датчик исправен/нет, остальные 31 - его адрес. Когда нужно перерисовать, проходишь циклом по массиву.
а сетка с квадратиками во вьюхе, которую дергает та, принимающая сигналы с обновлениями статусов, модель.
вообще можешь взять стандартную куть модель и стандартную табле вьюху - они уже сопряжены вместе и достаточно только обновить данные в модели (подписаться моделью на сигнал и обработать его в слоте), вьюха же сама обновит вид. с другой стороны это как посмотреть, подходит ли тебе такое решение по внешнему виду, и, возможно раскрашивать стандартную вьюху дороже, чем написать с нуля свои модель и вью.
Как именно? Напрямую что ли? paintEvent() вызывается методом update() или repaint(), насколько я помню. Не нужно явно вызывать paint() или paintEvent(), поскольку эти методы являются перегруженными и фреймворк вызывает их автоматически, когда ты, например, сворачиваешь/разворачиваешь окно, меняешь фокус или просто проводишь курсором над канвасом.
Причём тут кнопки и менюшки? У него вполне отчётливый вопрос:
Есть поток в котором опрашиваются датчики. Состояние датчиков отображается на дисплее в виде квадратика с заливкой определенного цвета. Ну там красный цвет, датчик не исправный, зеленый исправен
Лучшей задачи для Graphics View Framework и не придумаешь. Особенно если датчиков много. Завтра ему потребуется прикрепить какую-нибудь дополнительную информацию, которая показывается при наведении курсором на квадратик датчика и он будет два дня ковыряться в своей paintEvent-лапше.
Это хорошая идея выводить информацию при наведении курсора на квадратик. Но у меня проблема квадратиков нужно 128 штук а дисплей и меня 640x480. И размер квадратика такой что пальцем не попадешь.Нужна экранная лупа или что-то типа того. Не знаю в общем.
Тебя не поймешь. Спросил что вызывает paintEvent? Я ответила функция repaint. Она вызывает paintEvent сразу. Другие вызовы скорей приходят из очереди event loop. Кто их туда кладет, фиг его знает но ты их должен полюбому обрабатывать иначе виджет исказится.
Потому что ты не понимаешь, как устроено рисование в Qt. Почитай документацию:
Each widget performs all painting operations from within its paintEvent() function. This is called whenever the widget needs to be redrawn, either as a result of some external change or when requested by the application.
И городить своё рисование в такой задаче, особенно после той простыни, на раз сворачиваемой в цикл — OCHE плохая затея. Воспользуйся готовыми виджетами или, как EXL посоветовал, используй Graphics Items
Виноват. Управлять им надо. Получается если вписать квадрат в квадрат то получится внешняя рамка и внутри область в форме квадрата. Вот у рамки будет свой цвет а у внутреннего квадрата свой цвет. Управление цветами будет независимое.
Из твоего описания я не могу понять, можно ли изложенную тобой сущность уложить в один рисуемый элемент с несколькими параметрами (цвет рамки и внутреннего квадратика) или нет.
Если да, то в чём, собственно, проблема?
И что ты имеешь в виду под утверждением «управлять им надо»? Если только менять цвет – то зачем тебе этот квадратик как отдельный элемент? Я подразумевал под управлением, например, отдельное движение этого квадратика по полю или в пределах рамки и пр. сложные случаи.