Редактор форм - твой
Прозрачность - моя. Не вдруг конечно

А вот прошу пояснить при чем тут редактор формы. По всем параметрам панели выравненные по одному краю с Top позициями 0 10 20 30... должны разместиться на форме строго в определенной последовательности. Без вариантов.

Тогда все будет как есть

100 раз это все уже обсасывали

не помню чем все окончилось

А я тоже не помню

Но, не вспоминая, могу сходу сказать примерно такое:

Про "без вариантов": их может быть сколько угодно

Подозреваю (точного знания не имею), что сегодняшнее поведение редактора форм для Align - это вариант VCL. И нет никаких оснований считать, что это догма во все времена

Не думаю, что цифирьки 0 10 20 30... - Вячеслав писал ручками. Это сделала среда. И она же сделала "выстраиваются в непредсказуемом порядке"

В варианте KOL последовательность привязки определяется не координатами, а порядком создания.

Могут существовать и иные св-ва, определяющие размеры/положение контрола на паренте, кроме сегодняшних пяти. В том числе, не следует нам ограничивать творчество автора конкретного элемента, у которого может попасть возжа под хвост, чтобы сделать размеры контрола как квадратный корень из размеров парента. Не говоря уже о том, что в KOL для нашего Win есть заготовленные anchor-ы, к примеру. Да и св-во border тоже на привязку работает уже сегодня (в отличие от VCL, насколько я понимаю)

Точно так же, не думаю, что нам следует ограничивать авторов пакета. Ну предположим мы договорились с колегой tsdima, что пусть будет все по возможности одинаково. Было у нас в его форуме длинное обсуждение, какие порядки в схеме у нас существуют, и как нам к ним лучше привязываться. Но мне кажется, было бы правильно, чтобы и он имел право и на свое видение, отличное как от VCL, так и от KOL. Другой разговор: надо ли, чтобы было по разному - но право пусть имеет...

А такой пример я уже и не помню сколько раз (да и где - тоже) выкладывал:

Add(ChildPanel,8274163,98,105)
{
}
BEGIN_SDK
  Add(EditMulti,10085832,21,21)
  {
  }
  Add(Panel,13673908,35,105)
  {
   Width=135
   Height=266
   Align=1
   BorderWidth=20
   BevelInner=0
   BevelWidth=0
   Point(doColor)
  }
  Add(Button,5120866,98,35)
  {
   Left=10
   Top=10
   Width=115
   Align=2
   Caption="1"
  }
  Add(Button,10199695,98,77)
  {
   Left=10
   Top=30
   Width=115
   Align=2
   Caption="2"
  }
  Add(Button,4427141,98,119)
  {
   Left=10
   Top=50
   Width=115
   Align=2
   Caption="3"
  }
  Add(Button,2596789,98,168)
  {
   Left=10
   Top=70
   Width=115
   Align=2
   Caption="4"
  }
END_SDK

А есть еще и сплитеры со своими ненулевыми размерами

не вижу ничего более логичного, чем VCL расположение контролов в соответствие с их координатами. У кого меньше, тот и выше. Во всяком случае понятно, как влиять на это. Да и в Windows Explorer скажем при автовыравнивание можно взять иконку и впихнуть между двумя любыми файлами. Собственно не могу вот так сходу привести пример где бы была иная логика.


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

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

Есть люди, которые видят.
И у меня нет ни малейшего настроения объяснять Кладову его "нелогичность"



Не факт, что нужно.
Мне совершенно непонятна логика, когда некая проблема в одном инструменте (среда HiAsm) приводит к напрягам в сотнях экземплярах продукта (программы сделанные на HiAsm).
Причиной могут быть только неразрешимые проблемы.
В чем я не уверен совершенно.



А не факт, что:
а) это дороже по кодам
б) нельзя создать специального метода в KOL, меняющего порядок. Очень маленького и простого.

И единственный способ никогда не обсуждать такие вопросы - сделать зеркальные обработчики для Resize, с возможностью запустить из зеркал это же событие как для парента, так и для чайлдов.
Иначе: либо как я сказал
Либо мы делаем "свой KOL", считая себя умнее Кладова.
И, как следствие: выход постоянную поддержку последней их версии становится несбыточной мечтой.
Что мне не улыбается абсолютно. Хотя бы потому, что не считаю себя умнее.

видимо эта логика держится в строжайшем секрете


хех

Ну а мне видится все примерно так:
создавая некую среду с элементами где-то в чем-то мы обязательно имеем список их всех ввиде одного массива. Как только перед нами становится задача сделать Align, то не долго думая достаточно забацать примерно такую логику:
вот и всего делов-то. А вот чтобы сделать нормальное выравнивание тут извините нужно постоянной сортировкой элементов заниматься по координатам, соответствающим направлению выравнивания.

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


а кто будет заниматься собственно выравниванием?

Да бог с ней с логикой.
Из всего этого я могу сделать только один вывод: существуют разные подходы, спорить с любым - бессмысленно. Например:

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



Это на первый взгляд.
А не второй, и на третий получается код ~1К в PAS версии, и 600 байт в ASM
И ни одного слова из песни не выкинешь.
Мне известен уже смысл каждого слова по этому поводу (в KOL)



Мне думается, что это мог бы быть один из методов DLL-к из папки draw
Если автоматически искать этот метод для предка (WIN) при отсутствии персонального (который для вышеупомянутого сумашедшего) - могло бы получиться компактно и универсально.

Т.е., мне думается, что не следует пристегивать VCL-ские обработчики, а всякие там WM_SIZE и WM_MOVE передать на обработку в соответствующие методы draw-dll-ек
И предоставить интерфейс для послать эти WM_SIZE и WM_MOVE (или их аналоги) другим контролам.
Впрочем, интерфейс среды с dll-кой заслуживает отдельного обсуждения.

ну так в этом случае можно попробовать и вовсе избавиться от редактора форм и предаставлять только Handle от Parent окна, на которое нужно положить контейнер. tsdima вроде демонстрировал приличную работу инжектированных форм в среде, так почему бы и весь редактор так не сделать...

Ну я-то - хоть к пчелам в улей...

[size=-2]------ Добавлено в 12:46

А вот разобрался немного...
Это KOL виноват, а не я, однако

В нашем KOL такое:
А в последних KOL-ах уже правильно: И чего теперь делать - фиг его знает ...

KOL обновлять вероятно

Встряска еще та будет

[size=-2]------ Добавлено в 14:50
Может даже разумно будет выпустить альтернативный пакет с новой парой компиляторов, и постоянной поддержкой последних версий KOL

Не один день нестыковки будем выскребать....
Выскребем - первый анулируем.

можно и так.

Galkov, а поддержка FPC, народ возмущаться будет и вопросов немеренно задавать.