Комрады, насколько целесообразно прописывать код "светофора" в событие OnPaint формы:

Button1.Enable:= (varInt <> 1);
Button2.Enable:= (varInt = 1);

Если "нет", то почему?

в onpaint рисовать надо, а не состояния контролов менять

Так в учебниках написано. Хотелось бы услышать точку зрения с позиции того, что происходит "под капотом"

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

А зачем? Чтоб убедиться что кривой подход действительно кривой? Достаточно запомнить правильный подход и париться.

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

https://www.thoughtco.com/life-cycle-of-a-delphi-form-1058011 https://jamesmartinsandbrook.com/private/Tips/FornAct.htm https://delphisources.ru/pages/faq/base/form_life.html

WM_PAINT это сообщение с самым низким приоритетом, вместе в WM_TIMER, которые отправляются тебе после того как все активные сообщения из очереди обработались, причем сообщение от таймера самое низкоприоритетное. Переключать стейты контролов в WM_PAINT крайне не желательно т.к. в данный текущий момент времени идет отрисовка на невалидированом ректе и такое переключение может вызвать избыточный оверхэд, т.к. твои кнопки могут быть вне рамок этого ректа (Canvas.ClipRect). Для управления состоянием контролов существует Idle событие в котором и нужно это делать, причем там-же происходит и обновление состояний всех акшенов, а вот само Idle дергается тогда, когда очередь целиком пуста, либо ты вызвал что-то модальное со своим ЦВС и уже его очередь стала пустой (в этом случае модалка отправит WM_ENTERIDLE главному окну). Ну либо менять стейт нужно по изменению значений твоей переменной varInt зафигачив её свойством и меняя стейт контрола на сеттере. А если контрол, состояние которого ты хочешь переключать, еще и недайбог не правильно написан и внутрях, на переключение стейта дергает Invalidate даже если стейт не изменился, то ты, переключая стейт именно в WM_PAINT, получишь вечную перерисовку и отключишь нахрен Idle, ВСЕ таймеры по всему проекту и сами акшены вообще целиком. А если он дергает вообще Repaint - то еще и StackOverflow до кучи 😂

Это везде работает по разному

Сань, ты - голова! Вот это я хотел узнать👍🏻

Ну вот и узнал :)

А представляешь, сколько б мне пришлось времени потратить, что б это все узнать, осмыслить и сделать выводы? А тут прикинулся шлангом и, оп-па, тебе все рассказали 😁 Спасибо ещё раз

За этим тут и сижу

этот метод всегда работает )

Вот и я смотрю, все хитрые 🙂

можно еще заведомо неверный ответ написать, чтобы тебе объяснили )

Могу добавить что Саша далеко не все возможные глюки описал. Могут быть дополнительные проблемы с буфферизацией, отрисовкой в структуре парент-чайлд, элементов с полупрозрачностью, не говоря о том что в общем случае ты не знаешь что вызывается на изменении свойства. ...Но иногда может и прокатить

Да я ж не настаиваю, мне внутренняя кухня в этом контексте была интересна. Ибо в "книжках по Дельфи" все описано либо примитивно, либо архисложно.

Вот поэтому, чтобы понять внутрянку лучше - нужно компилировать простые кусочки, кормить их в IDA Pro и разбираться, а потом еще и внешними отладчиками смотреть

+ изучить азы ассемблера 😁

А как программировать без понимания того, как работает процессор?

Питон?))

Так есть же компоненты и события к ним. На первых порах для однооконного приложения достаточно 🙂

Ну мы сейчас не говорим про программистов отступами, где отсутствие готовой библиотеки для какой либо задачи = трагедия и нерешаемая задача

Легко. Гугл программисты так кодят

Ну таки и результат соответствующий)

Да. Я перед словом "кодят" пропустил одно слово. Итак понятно. :)

Ну мыцж говорим о программировании, что подразумевает реализацию каких-либо алгоритмов и всякое такое, а не шлеп, клик - чет написал в сгенереном обработчике, вроде работает)

Книжки еще читать нужно правильные, Рихтера, Фень Юаня, Шрайбера и т.д.

Это если ты виндострадалец