Dilma писал(а):
видимо эта логика держится в строжайшем секрете Да бог с ней с логикой.
Из всего этого я могу сделать только один вывод: существуют разные подходы, спорить с любым - бессмысленно. Например:
Кладов писал(а):
И не надо мне говорить, что в VCL таких проблем нет. Там другие проблемы есть. Например, неожиданное изменение визуального порядка выровненных визуальных элементов после включения Visible в свойство true. Особенно неприятное, когда свое положение на неправильное меняет, например, сплиттер. Там для борьбы с подобным глюком приходится своим кодом менять значения свойств Left/Top проблемных контролов, и это решение ничуть не менее обходное, чем использование Global_Align в KOL.Ну не хочу я с таким спорить...
А если не спорить, значит надо предоставить возможность воплощать "свое видение".
Если развивать это логически, то и тому сумашедшему автору элемента, который именно для своего супер-пупер контрола вообще ни с кем не согласен.
Dilma писал(а):
Ну а мне видится все примерно такЭто на первый взгляд.
А не второй, и на третий получается код ~1К в PAS версии, и 600 байт в ASM
И ни одного слова из песни не выкинешь.
Мне известен уже смысл каждого слова по этому поводу (в KOL)
Dilma писал(а):
а кто будет заниматься собственно выравниванием?Мне думается, что это мог бы быть один из методов DLL-к из папки draw
Если автоматически искать этот метод для предка (WIN) при отсутствии персонального (который для вышеупомянутого сумашедшего) - могло бы получиться компактно и универсально.
Т.е., мне думается, что не следует пристегивать VCL-ские обработчики, а всякие там WM_SIZE и WM_MOVE передать на обработку в соответствующие методы draw-dll-ек
И предоставить интерфейс для послать эти WM_SIZE и WM_MOVE (или их аналоги) другим контролам.
Впрочем, интерфейс среды с dll-кой заслуживает отдельного обсуждения.
Поиск
Друзья
Администрация