k0rvin, согласен 

ещё раз посмотрите мои примеры, я не призываю к коду типа


я имею в виду


области видимости вполне обозримы, даже более обозримы и "узки".

Это сообщение отредактировал(а) k0rvin - 4.6.2010, 14:49

Хорошо, а для каких целей вам надо ограничивать область видимости. Я не вижу разумных объяснений почему это может быть удобно и оправдано. Кроме того, если вам понадобиться использовать еще в 10 циклах ниже, каждый раз прийдеться объявлять переменную, и хорошо, если у нее короткое имя типа.

Это сообщение отредактировал(а) cemick - 4.6.2010, 15:54

1) это удобно и оправдано, потому что правильно.

для случая 10-ти циклов я и приводил выше вариант



+ можно добавить в for некоторый вывод тиов (тип счётчика выбирается как наиболее широкий из типов a и b), тогда получим возможность писать так:


т.е. возвращаемся к текущему состоянию, только переменная-счетчик видна только в теле for

2) я же не говорю, что использование let должно быть обязательным. кто не хочет -- юзает var в начале подпрограммы.

На самом деле удобно очень. Вписал for + Tab + i (переменную цикла) + Tab + Screen.Forms + Tab + пишешь тело цикла.

Во, вспомнил.
Я давно мечтаю, чтобы в дельфи все невизуальные компоненты выкладывались не на форму, а на какую-нибудь специальную панель в IDE. А то если много компонентом, то трудно проектировать форму.

Но!!! В одной из последних версий эксперта GExperts почти реализовали мою мечту. Они добавили команду "Hide/Show Non-Visual"         и теперь можно прятать невизуальные компоненты формы.

Добавлено через 1 минуту и 40 секунд
И ещё один большой недостаток среды в том, что она не запоминает положение всяких вспомогательных редакторов. Таких как редактор ActionManager`а, редактор persistent-полей набора данных. Частично GExpert тоже запоминает и восстанавливает размер этих окон и положение, но не всё.

согласен, как  в вижуал студии например. особенно фигово становится, если отключить выравнивание по сетке (я предпочитаю выравнивание относительно компонентов)

В принципе, все Non-Visual можно убирать в DataModul, но это лишний модуль, так что поддерживаю.

А обязательно невизуальные компоненты бросать на форму? Можно ведь с кода создавать...В визуал студии идеология заставляет так делать.

можно, но зачем загромождать исходник "бесполезным" кодом?

Да ладно, сколько там того кода    Или лучше загромождать форму?

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

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

Ты не забывай, что Delphi - это RAD. А зачастую визуально проектировать гараздо быстрее и проще. Возьмём, например, проектирование пользовательского интерфейса с использованием компонентов: TImageList, TActionList, TToolBar, TMainMenu, TPopupMenu 3 шт.
Как думаешь, быстрей будет набросать компонентов на форму, связать, загрузить картинки или писать это всё в коде + запихивать картинки в ресурсы с компиляцей %).
Да, да многие супер-буппер программеры скажут, мол это всё былокодерство и что настоящий программист всегда идёт в обход пишет всё ручками... ну ну... пишите, никто ж не запрещает 

А меню, значит, невизуальный компонент. 

Зачем для каждой формы?    Пары будет достаточно.  
Один для ImageList и т.п., другой для данных (в случае работы с БД).
Другое дело, что такой подход усложняет код и не всегда реализуем.
Было бы гораздо удобнее, если бы в редакторе невизуальные объекты помещались не на форму, а на отдельную панель, но при этом относились к данной форме. Нечто похожее в VS реализовано.

В той же VS все больше "графического" программирования (работа мышкой).

...и даже сочувствуют.  

Значит ты не проектировал высоконагруженные приложения, где 100-200 окон.

Добавлено через 37 секунд

Ну ладно, меню можно и непосредственно на форму бросить.

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

здасте приехали         

У меня сейчас в проекте порядка 100. В дата-модуле все, что касается доступа к данным. Есть отдельный дата-модуль, где хранятся некоторые невизуальные компоненты (общего пользования) приложения. Остальное все в пакетах.