А еще есть Layout'ы всякие.

Это наверное позже седьмой версии появилось?
То я и не ковырял вовсе. Это уже не труЪ делфи   

В данном случае я не столько о делфи, сколько в общем. И чем layout'ы не Ъ-делфи?

Проверил -IDEA масштабирует все контролы и шрифты в соответствии с установленным DPI.




Все прогрессивное человечество давно использует для этого layout manager-ы. И только дельфисты что то там из кода двигают 



У меня есть опыт и того и другого, и я пришел к выводу, что при наличии опыта написание гуя руками дает лучший результат чем дизайнером. Плюс опыт моих коллег, минимум две знакомые командами разработчиков отказались от дизайнеров в пользу ручного написания.
Правда надо заметить, что во всех случаях использовались нормальные языки с layout manager-ами, а не с "попиксельным позиционированием".

Ну я то не дельфист.
А скажите пожалуйста, в каких единицах измерения вы ставите отступы между элементами управления?



А кто говорил что нужно попиксельно позиционировать? Я не знаком с layout manager-ами, но что-то мне подсказывает что используемые мной средства будут хуже. Тем не менее, в конечном итоге приходишь к выводу, что в дизайнере делать лучше. Подумайте сами, ведь изначально гуевые приложения начали создавать с кода, потом пришли к дизайнеру форм. Однако всем хочется пробовать что-то новое, вот и используют мвс, и первое время даже начинают видеть в этом профит. Но вот есть куча моментов когда это не удобно, перечислю которые первые приходят в голову: 1. Как я уже говорил, пока не запустишь приложения, не будешь знать как оно выглядит, и хотя ты будешь знать что элемент А находится за элементом В, всё равно это всё не сможешь оценить, если не увидишь всю картину. 2. приложения созданные в дизайнере проще модифицировать. так уж получается, что требование к ПО постоянно меняются, а как ни странно, приложение на мвс сложнее модифицировать при изменении структуры, так что разделение логики и представления в мвс это понты для приезжих. 3. иногда не хочется весь этот огород городить с мвс, а хочется по больше сосредоточится на основной задачи приложения, дизайнер форм делает всё гораздо быстрее, кроме того, не приходится писать однообразный код реализации мвс.

Судя по тем заблуждениям, что ты высказывал раньше(относительно экшн, относительно нагромождения контролов, не способного работать с разными разрешениями), опыта у тебя в одном, определенно меньше нежели в другом. Выводы, при таком раскладе, делать не совсем корректно.

Здесь отчасти согласен. В этом утверждении, определенно что-то есть. При проектировании структуры БД мне определенно проще использовать ddl, нежели графические дизайнеры схемы данных. Припоминаю, что некогда функционал для ПЛИС мне было проще реализовывать средствами vhdl, нежели используя графический редактор логики, предоставляемый производителем ПЛИС. Но в обоих случаях, достоинство декларативного языка обуславливается вполне определенными недостатками графических средств. В обоих случаях я начинал с графических дизайнеров, и, лишь не удовлетворившись ими, начинал изучать семантику декларативного языка. От ворда, к примеру, я не ушел ни к какому языку разметки текста. От делфийского дизайнера форм, я не ушел к динамической компоновке форм. Это говорит о том, что эти средства в достаточной степени покрывают мои потребности. То, что вам проще херачить формы лапами, говорит лишь о том, что прочие средства предоставляемые вам платформой еще более убоги.

Это сообщение отредактировал(а) Zloxa - 25.5.2012, 10:41

Использовал дефолтные (99% процентов случаев)  









Ты про TAction? Так я про него ничего и не говорил, я говорил про то как себя по умолчанию ведет визуальный редактор Дельфей. Если бы он спрашивал имя для нового TAction, а потом создавал отдельный класс для него и регистрировал как обработчик события, тогда бы я бы согласился, что редактор гуя делает максимум того, на что он способен. Но насколько я знаю, он этого не делает.

И зачем это нужно там, где это не нужно?

Затем чтобы приучать начинающих быдельфи програмистов к хорошему стилю  

Разработчики DevExpress пошли дальше и создали бомбу по мощнее в лице dxBarManager 
А TActionList + TcxImageList + TdxBarManager весьма сильно разгружают программиста по времени.

Добавлено через 4 минуты и 48 секунд

зависит от компонентов
для дельфи много компонентов, позволяющих строить "резиновый дизайн"

Добавлено через 10 минут и 16 секунд


1. Можно из кода, а можно и не из кода.
2. Ты сам подумай, если не ты в своём приложении двигаешь НЕ из кода, то кто-то другой до тебя в любом случае двигает из кода  

Пропущено ключевое слово сторонних  




Layout manager уже написаны и хорошо протестированы сотнями программистов. В отличие от самописного управления расположением компоненов.

От проекта вроде как не отказались, но приоритет этой новой нескучной POS на жаве, сильно задвинули.
В параллель пустили новую не скучную POS на 1С.
Разработка в обоих случаях - java и 1С ведется двумя человеками. Кастом - дичайший. 1С используется скорее как платформа, нежели решение.
Выводы пока делать рано, но кое-что уже можно попытатсья сравнить.

Период от начала разработки - выход на интеграционные тесты на жаве занял более полугода. 1С - менее месяца.
За две недели интеграционного тестирования с POS на 1С мы продвинулись по процессам на два шага дальше, чем за два месяца интеграционного тестирования с POS на Java.
1Cники ни разу пока не упомянули словосочетание "хорошая практика", в дискуссии на подобные темы не пускались. Вместо этого: "надо? Сделаем!". 
Технические вопросы, вроде того, как изменить формат XML сообщений обмена, чтобы он был воспринят "гибкими" фреймворками, 1Сниками вообще не поднимались, вдули как им дали, не привередничая. Вобще с 1Сниками обсуждалось больше прикладные вопросы, чем технические. До обсуждения прикладных вопросов с Java программистами, мы вроде как и не дошли вовсе.

Добавлено @ 10:43

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

Это сообщение отредактировал(а) Zloxa - 31.5.2012, 11:32

Буквально несколькими сообщениями ранее делфистов ругали за то, что они этого не делают   

Где?

http://code.google.com/p/fpos/wiki/FPOSWiki
Many people judge that Pascal can't be used to write an OS, this project will prove that they are WRONG.