Я птичка, мне такое сложно. Хочу все эти тайные знания спрятать "под капот" и забыть.

капот дымиться периодически будет :)

M привет

честно перечитал. доводов не нашел. Но похоже понял что вы все за вред толдычите. Данный метод подразумевает отсутствие привычных button1click и запуск всех gui действий через экшены а дальше через commandmanager. Поэтому "паралельного" выполнения разных команд нет и быть не может (но есть нюансы с завершением предидущей команды). Но это не минус, в сложном приложении button1click и иже не место.

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

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

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

основной минус у меня получается решен. в обработчик кнопки я попадаю 2 раза, но там только commandmanager.runcommand('DrawLine') и внутрь команды 2 раза попасть не получится. источники заполнения - мышь, командная строка, результат выполнения предидущей команды

нет, основной минус это таки использование недокументированных знаний о внутренней реализации UI фреймворка. В какой-то момент она может поменяться. Равно как и уже может быть другой на какой-нибудь платформе. Так что даже если все пока идеально работает, это не значит, что проблем нет.

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

согласен. тут я ниже кода lcl общего для всех поддерживаемых платформ не опускаюсь. Но да с этой стороны могут быть проблекмы

многопроточность в себе проблем принесет еще больше наверно((

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

что практичнее: i:=i*33 или i:=i+i shl 5 ?

i:=i*33

т.е. imul удобнее чем shl/add по ассемблеру если смотреть?

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

но читать-то мне и низкоуровневое приходится :(

А сколько миллионов раз в секунду это нужно считать?

ладно,пусть решает компилятор

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