Раньше с таким сталкивался, но только 1 раз. Видел у Бита... когда они свои панели в типовые документы добавляли.
А сейчас наткнулся в типовом ЗУПе 3.1.8 ОбщаяФорма.ВводСтажаСотрудников весь интерфейс написан программно. Это модно так? или чтобы удобнее было в EDT потом код парсить?

(0) Это удобно.

(0) Модно. Удобно. Зависит от поставленной задачи.

В доработках очень удобно - создал процедуру создания/редактирования элементов и если при обновлении изменения перетерлись, то не рисуешь форму заново, а добавляешь одну строчку вызова процедуры

(0) Я так формы на Tubo Vision в 1993 году рисовал :) Уже тогда было модно и удобно.

Чертишь прямоугольник с клеточками 80 в шину и 25 в высоту и рисуешь форму.

(4) А зачем на турбе руками рисовать было? Там же редактор ресурсов был. Прямо так и рисуешь, потом код получаешь

(5) Это уже на Делфи под винду было, позже. А Turbo vision еще был под текст.

(5) Вот на Foxpro 2/6 такое помню, рисовал, получал код. На TV не помню.

(6) Нет. Именно под турбу досовскую.

(8) С 94 года по 95 на турбе уже не программировал, потом был Foxpro + 1с первых версий, значит, уже не застал.

(0) В ЗУПе много таких мест. Общая форма настройки ответственных лиц полностью рисуется программно. Тоже самое и с реквизитами подписантов в документах.
Здесь ноги растут от библиотечного подхода к разработки конфигураций. Например, создается универсальный механизм для работы с подписантами/ответственными лицами. И для того, чтобы его было проще интегрировать в различные формы различных конфигураций делают программную отрисовку элементов форм.

(0) Попробуйте обновить конфу, в которой элементы управления добавлены на форму средствами визуального проектирования. Времени убьете немерено и так из релиза в релиз мучиться. А код скопипастил в 1 мах - и готово. Всякие там обновления с приоритетом если что-то удалилось оставят мусор. Да и так проще добавить однотипные элементы в 60 форм типовых объектов конфигурации.

(4) я так в школе на qbasic рисовал интерфейс нортон коммандера ))

SCREEN 9
WIDTH 80, 43
COLOR 2, 0
LINE (0, 0)-(640, 350), 15, BF
LINE (3, 3)-(637, 347), 0, BF
FOR n = 1 TO 1000
x = RND * (630) + 5
y = RND * (340) + 5
x3 = RND * (630) + 5
y3 = RND * (340) + 5
c = RND * 15
LINE (x, y)-(x3, y3), c
IF INKEY$ <> "" THEN 1
NEXT n
1 :
CLS
LINE (100, 100)-(190, 250), 15, B
PAINT STEP(-1, -1), 8, 15
LINE (100, 100)-(120, 90), 15
LINE (120, 90)-(170, 90), 15
LINE (170, 90)-(190, 100), 15
PAINT (145, 95), 8, 15
LINE (110, 95)-(180, 95), 15
LINE (120, 95)-(130, 90), 15
LINE (170, 95)-(160, 90), 15
LINE (105, 105)-(185, 115), 15, B
LINE (105, 105)-(185, 125), 15, B
LINE (115, 110)-(175, 110), 15
LINE (125, 108)-(140, 112), 15, B
LINE (105, 135)-(185, 180), 15, B
FOR n = 110 TO 180 STEP 3
LINE (n, 240)-(n, 220), 15
LINE (n, 215)-(n, 195), 15
NEXT n ну и так далее...

(11) как я видел в одном посте на схожую тему: "При обновлении такие типы обычно сливаются".

(13) Почему сливаются!? Обновлять такое - работа не бей лежачего, на самом деле.

(14) Особенно, когда выходит большой релиз с переименованиями названий/изменением параметров вызова общих модулей, удалением кучи процедур из модулей форм, а добавленным нетиповым процедурам иногда забывали ставить префикс разработчика. И сидишь думаешь: удалять это говно или нет? Типовое оно, или кем-то написано? Конечно же оставляешь от греха по дальше. Штук 80 на все формы. И ловишь ошибки при открытии, так как оставленные процедуры ссылаются на несуществующие модули или не могут до них достучаться.

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

(6) был визуальный редактор под турбо-вижн. Причем, если мне не изменяет память, там было два варианта - работа с ресурсными файлами (которые там тоже были), либо же генерация готового кода на Object Pascal, который создавал соответствующие нарисованным диалоги. Востребовано было в основном для диалогов - там все-таки много кода ручками писать надо было.
Про винду даже и речь не идет, там все это было изначально и стандартно. А вот под TV это была не совсем стандартная примочка, по-моему, сторонняя разработка.

по существу - лично я полагаю нормальным, когда доступно оба варианта. То бишь и программное создание формы, и с применением визуальных средств.

(17) Вот честно скажу - не помню, откуда я её тогда брал, интернетов-то не было... По-моему оно в комплекте шло каким-то образом...

Можно же поставить и проверить http://old-dos.ru/index.php?do=show&id=2094&mode=files&page=files

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

(21) Ну я когда то на бейсике для ямаха мсх2 наваял редактор рисунков (по типу пайнта) который переводил действия в код для рисования.

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

(7) нечего там было рисовать... платформа могла разместить поля, и возвращать результат.. о каком рисовании речь?