Доброго.
Берег тему по пятницы, да простят меня админы за мелкий холивар.
Но вот какое дело.  Попросили меня помочь друзья.
Так вот у 1с на обычных формам в толстом клиенте. Там несколько нестандартное использование 1с. Не как учётная система, а некая система агрегации данных с промоборудования.
В общем, самописка. И на УФ и новые платформу переходить пока не планируется
Но фишка в чем. Их аргументы.
Работает быстрее.
Нет проблем, и просто подключение разного специфического оборудования, там много ВК своих написано.
Можно рисовать интерфейс, какой надо, у них разные мониторы на разных постах, так вот формы для каждого своя.
И главное, есть гарантированный модальный режим, что значительно ускоряет  обмен с разным оборудование.
Оно вот реально так? Толстый клиент и ОФ реально быстрее и проще?

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

(37) +

2013 год :)

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

Получится на практике, что разные ветки релизов ведут себя в файловом режиме и толстом клиенте по разному. Единственное оправдание может быть, если база абсолютная самописка и на ОБЫЧНЫХ формах тогда реально лучше брать далеко не самый новый релиз.

(41) Плюс еще на самописке происходит фиксация релиза и разработка ведется с учетом тараконов именно этого релиза. А потом окружающий мир уходит вперед (например, с новыми версиями SSL), и от разработчиков таких самописок начинают исходить стоны, что "ваша 1С дерьмо"..

(30) при чем тут это если (0) ?

(39) > отрисовкой контролов попиксельно

Вот и выросло поколение, которое не помнит как в 7.7 на стартовом сплеше картинка морфировала и вешала наъ всю отрисовку на терминале =)

(44) Та ? Это отключалось на раз..

(45) Лицензионными методами? =)

(46) /NoSplashScreen

более того, у меня на 77 щас такая заставка, всё лень dll поменять, так и осталась с поправленным ресурсом
https://i2.piccy.info/i9/4bdb59e919cc6bb89d567c62ebb33163/1643361590/85198/1452774/77.png

(47) Во-первых NO_SPLASH_SHOW, а во-вторых это только для OLE объекта V77.Application =)

(48) > так и осталась с поправленным ресурсом
Воооот, начинается =)

(0) Нет. Нет, нет.

Давно работаю с УФ как пользователь

И сложилось у меня впечатление - что командный интерфейс (самой программы, а не форм), и основной экран (начальная страница) - вещи просто бесполезные и из пальца высосанные + разделение команд на действие/навигация

(0) Очевидно же.

(50) ну а то, зато 7.7 - это просто сверхзвук..

(44) Отчего же, все прекрасно в курсе этого хитрого морфинга заставки. Можно её прикрыть другим окном - и тогда тормозов не будет) А ещё, помнится, был патч, который убирал эту анимацию.

(0) Шож не си с ассемблерными вставками?

(55) > Можно её прикрыть другим окном
Отличный вариант. И для градиента 8.2 подходит, да =)

(56) Эх, помнится, был в шоке от игрушки Transport Tycoon под DOS. Там реально создали многооконный интерфейс, с неограниченным количеством окон, каждое окно свободно перемещалось, и в нём отображались живые объекты игрового мира с анимацией в реальном времени, как будто реальный вид сверху с вертолета. И всё это великолепие просто летало на 486 компе, без малейших тормозов.

Вот что бы этим разработчикам не делать операционную систему (или 1с)?! )

Вся эта тормознутость идет от мультиплатформы.
Скажем больше спасибо линуксу на десктопе

(59) Неа. Они могли бы под линуксом использовать скажем GTK, а под виндой GDI. И ничего бы не тормозило при отрисовке. А они предпочли закат солнца вручную организовывать - рисовать контролы пиксельной графикой. Чтобы красиво.

(58) >  что бы этим разработчикам не делать операционную систему
Вот не надо. Были уже попытки.

Вот так вот выглядело убийство процесса
https://i.stack.imgur.com/e0jya.jpg

=)

По мне, так УФ удобны для веб-клиента, мобильного и, возможно, тонкого клиента. В остальных случаях удобнее ОФ и толстый клиент. С точки зрения удобства отладки и разработки ОФ проще: трассировщик с УФ и фоновыми задачами не  очень удобен. По факту УФ более тормозной и более требователен в ресурсам компа, хотя должно быть наоборот. Усложнять там где не надо - это глупость и вредительство. Интересно, может кто знает, где-нибудь есть сравнение по трудозатратам на одинаковые вопросы разработки и сопровождения УФ и ОФ?

(62) > С точки зрения удобства отладки и разработки ОФ проще: трассировщик с УФ и фоновыми задачами не  очень удобен.

Разверни, пожалуйста, свою мысль.

ОФ и файловая - это получается даже однозвенка.
Если в базу писать с одного рабочего места,то никаких накладок не будет.
Но,1с не умеет напрямую работать с Com-портом,то есть там,явно,используются или внешние компоненты или Com-объекты.
Далее,вообще не понятно,а чем,например Access runtime,который с com-портом работать умеет,не угодил?

Есть хорошая фраза: "Браузеры создавались для просмотра порнухи, а не для ввода данных в учетные системы". Отсюда все страдания с УФ.

(0) ассемлер уаще быстрый. А вообще я базуху буду писать на толстом клиенте.

(66) > буду
Ты еще не начал, что-ли?

(65) > Отсюда все страдания с УФ.
Просмотр порнухи же и получается. Что не так?

(63) Вот такие конструкции, как пример:     
ОписаниеОповещения = Новый ОписаниеОповещения(
        "УстановитьПараметрыАвтообновленияСпискаПродолжение",
        ЭтотОбъект,
        ПараметрыОбработчика);
ОткрытьФорму("ОбщаяФорма.НастройкаАвтообновления",
        ПараметрыФормы,
        Форма,,,,
        ОписаниеОповещения,
        РежимОткрытияОкнаФормы.БлокироватьОкноВладельца);
Их отладка только через точку останова.

(69) А что, асинхи уже запретили?

(69) Это ты немодальность фоновыми задачами, что-ли, называешь?

(71) Это не удобно. И в абсолютном большинстве случаев не нужно. Как я это называю - не важно.

(30) >> А если нет сервера 1С?

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

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

>> УТ10 в файловом режиме спокойно 10-20 пользователей тянула.

А умела эта УТ 10 работать в веб-клиенте? А в тонком клиенте на плохой сети?
1С уже довольно давно ориентируется на клиент-серверный режим работы.
Файл-серверный оставлен скорее для баловства, тестирования, разработки (хотя и разработку лучше вести на клиент-сервере).
Для мелких контор есть либо облачные решения, либо мини-сервер.
И это, ИМХО, правильно. Пытаясь сделать счастливыми всех можно в результате не угодить ни кому.

PS Кстати про мини-сервер 1С. Я бы увеличил количество подключений с 5 до 10 или даже 20. Быть может чуть-чуть повысив цену. Но 1С на это вряд ли пойдёт чисто из маркетинговых соображений.

(72) > Как я это называю - не важно
Весьма важно. Это дает понимание о твоем уровне владения предметом и общей терминологией, позволяет лучше подбирать слова и обороты для общения с тобой.

(70) Вопрос не про запретили. Вопрос: Зачем? Может сейчас у программистов зарплата сдельная и платят за объем кода? В большинстве случаев без выполнения того самого кода, что в "При закрытии" далее пользователю что-либо делать нецелесообразно пока эта процедура не завершится. Так зачем её в асинх?

Еще одна особенность - если использование синхронных методов запрещено (продвижение новых технологий в жизнь), и соответственно метод ПодключитьВнешнююКомпоненту() и т.п. не работает. Использовал НачатьПодключениеВнешнейКомпоненты() и т.п. И вот тут оно работает быстрее говорят.

(76) На асинхронных типа быстрее.

(75) > пользователю что-либо делать нецелесообразно пока эта процедура не завершится

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

(62) >> где-нибудь есть сравнение по трудозатратам на одинаковые вопросы разработки и сопровождения УФ и ОФ?

Какой смысл в таком сравнении?
Даже если вдруг кто-то докажет, что разработка и сопровождение в N раз менее трудозатратно, то что это поменяет?
Ответ: НИ-ЧЕ-ГО.

И добавлю. Совершенно не факт, что результат сравнения будет однозначно в пользу ОФ и толстого клиента. Где-то, как-то, что-то ± одинаково.

(0) смотря для каких целей. В локальной сети - в общем случае да.
В случае его натягивания на филиалы, подключенные через инет - нужны костыли в виде RDP, тогда как УФ и сами шуруют без RDP.

Разработка то фигня. Больше времени уходит на тестирование и отладку. Ну и понять чего им надо было.

(78) Психолог, однако. Тебя куда-то в крайности кидает. Зачем одни модальные? Речь идёт про удобство разработки, пользования и сопровождения. Сейчас код стал сложнее, а задачи решает те же и почти с той же скоростью. Пользователь просто не заметит разницу в 0.5сек при закрытии окна. Зато нужно более "грамотных" программистов искать и больше времени тратить на решение тех же задач.

но в разработке - сложнее, сама отрисовка форм - медленнее, потому что это жабаскрипт, а не WinAPI...

(81) Вот и я о том же!

чисто по величине кода толстый компактней.
никаких насервере/наклиенте

другое дело, что промышленные системы дело само по себе традицонно, во-первых, консервативное, во-вторых, не любящее чрезмерно высокоуровневых подходов. Я, честно говоря, удивлен выбору 1С вообще. С моей точки зрения разумнее было бы Visual C/C# или Delphi.

(80) Может там настройки какие-либо скрытые есть, но попытка запустить удаленных пользователей в тонком клиенте на УФ провалилась. Пришлось на RDP вернуться.

(86) Было раньше Delphi. Но на 1С быстрее оказалось. Да и прогов как-то больше и дешевле они.

(87) оч странно. У меня все получилось сразу же с БП 3.0.

(87)Странно у меня продажников толпа так бегает, кто в вебе кто на ТК.

(88) там проблема в том что в 1С муторно пилить всякие компорты и сетевое взаимодействие - ВК нужны и не все что надо они обеспечивают. А на той же дельфи это все можно делать нативно с применением функций API операционной системы.

(91) Ну не знаю. Мне надо было как-то мелкую утилиту, типа дубликатор шрихшкода, сканирует и печатает два-три штуки. Думаю сейчас развлекусь сделаю на C#, а вот болт тебе, норманого пример не нашел. А секасом заминаться как-то расхотелось и сделал на 1С с БПО.

(91) в 1С очень удобно работать с отчетами, в в Delphi это тоже можно, но муторно. Плюс если на базе 1С основная учетная система не нужно обучать пользователей, держать доп.программеров (от которых сильно зависишь, т.к. их мало) и т.п. Но 1С не может работать с RS-485 или ТСР вот и приходиться делать костыли (на Delphi) для сбора данных в промежуточные базы, а уже из них забирать в 1С. А после того как забрал нужно эти данные толи правильно, толи красиво вывести пользователю. И не в виде отчета, а в виде обработки: для принятия решений и интерактивного взаимодействия, а вот тут и встает вопрос каким интерфейсом это удобнее реализовывать.

(93) у меня особых проблем с отчетами нет, FastReport юзаю, он мало чем отличается от 1Совского олдскульного механизма, который был до СКД.

(92) Была похожая задача: идёт сканирование ШК на потоке. Пришлось писать службу на Delphi для сохранения в MSSQl а уж из него в 1С забирать. 1С увы не может (или я не нашел как) в фоне сканировать com-порт.

(0) > И главное, есть гарантированный модальный режим, что значительно ускоряет  обмен с разным оборудование.

А можно поподробнее этот момент? У них оборудование к рабочим местам подключается? Серверной части нет?

С остальным соглашусь (для их случая).

Интересно, что они будут делать, когда появится несколько территориально удаленных площадок.

(95) Все упирается в подходящую ВК. И в отдельный сеанс, где эта компонента будет висеть и ловить данные.

(96) Там несколько компов которые стоят по цехам. Там все локальное, Сервера нет. Раз в час сливают инфу на сервер.
Ничего не будут делать, цеха и так разбросаны, типа уже есть несколько территориально удаленных площадок.

(98) Что ж, отличный кейс для "1С годится не только чтобы деньги считать".

(99) Это кейс "нету денег на нормальный прогов или фирменное ПО"
100 однако

(100) Если на 1С вышло дешевле при приемлемом качестве, чем не кейс?

Видел биллинг ЖКХ на 1С. Тоже на ОФ.

Кодинг на ОФ - ты просто берешь и заходишь в распахнутую дверь.
Кодинг на УФ - не дорогой вот так в дверь войти нельзя. Дверзь азкрыта и окнна заколочены наглухо.
Вот тебе замочная скважина! Туда и лезь. Класс! Спасибо дорогой фирме 1с что вывалили все кишки нам на голову.
И ладно об оно шуршало в вебе как боженька. Нет ползет со скоростью улитки. Ради чего все это, чтобы что?

Почему нельзя было как в Vaadin рисовать все на сервере и отдавать готовое веб клиенту - непонятно.

А как вам то что местами вполне логичные для клиента типы ВОООБЩЕ не реализованы, или поведение их косое. Привет таблице значений.
Сфейхуа про нее забыли?! Аааа мол слишком большое тягать не надо. Рили? Ну так я и в массив могу ярд элементов запулить и положить клиент.
Нет просто тупо забыли и забили. Кодинг в УФ это пусть самурай у которого нет цели а лишь путь - вечная борьба с ограничениями и поиск обходных путей.

Вот например ДанныеФормыСтруктура нельзя конвертнуть в Структуру. ЛОЛ вы серьезно? Как вам потерянная галочка у реквизитов формы "изменяет данные" нет ее хотя у команд есть.
В чем логика? Забыли. И не надо мне про флаг модифицированность я и сам знаю, почему этого нет в платформе? Если оно делается легко и просто, да и было с времен 7.7. В чем тут прогрессивность?

Я уж молчу про то что 1с устали отбиваться и в некотрорых местах явно сдались.
Это я например про "найти текущую строку" в списке для объектов которую также забыли же. Но ведь реально забыли, но потом вынуждены были сделать когда им напихали полную панамку.
И преподнесли ведь как величайшее достижение. Ахах. Ржу аки конь. Привет функционалу из 7.7.
И самая мякотка - событие ПриПолученииДанныхНасервере у ДС которые разрабы просрали, и тоже доказывали всем что оно вам не надо это все не эффективно.
А сколько тут на мисте копий было сломано ух. В итоге что? Сделали! Но только для ДС а для Табличных частей опять забили! Или там эффективно, а тут нет?
Вот где тут логика??? Это ли удобство? Это ли верх инженерной мысли разрабов платформы, который нам простым 1с-никам, не постичь?

Я не знаю как вы, а мне вот хочется работать с платформой в которой обо мне как о разрабе подумали и позаботились. А не вот это вот всё...
Да спасибо хоть стали слушать последнее время комьюнити и потихоньку УФ стали худо бедно съедобны. Но до уровня ОФ им еще как до луны. Увы и ах.

ИМХО все что можно соорудить на УФ можно на ОФ и гораздо ГОРАЗДО, на порядок проще. Обратное не равнозначно - иногда да, но чаще НЕТ. Разумеется все это справедливо если опустить веб клиент.

Ну а если самоцель веб клиент - у меня для вас плохие новости. Цель может и достигнута, но явно лишь частично. Да для Фреша, наверное, подойдет но для чего то реально нагруженного.. ну такое.
А то зачем они развивают Элемент если все лучезарно в вебклиенте??? Объясните мне. Ответ прост - ТУПИТ веб клиент. Тупит хоть оптимизируй хоть нет. Без слез на официальные демки выложенные в
публичный доступ смотреть не возможно. Вот вы серьезно считаете что ЭТО быстро и удобно? Ну тогда и суп ешьте вилкой.

Думаю 1с понимает что нужен принципиально иной подход. Который и модульность настоющую даст и логику клиент-серверную пересмотрит.... А пока... как были УФ надстройкой и игрушкой так и остались.
Надеюсь мы доживем до этого времени когда выйдет 1с элемент 1с Камаз или 1с9 или что еще придумают.
А пока продолжаем наблюдать...

(103) да-да да.. даже сделали ширину и высоту контрола, хотя ранье твердили - что это вам не нать, тут полный автомат

Через сколько лет, в ДС появится галка отбор по значению в колонке ? Или реальный поиск без отбора в списке в уф ?
Делаем ставки..

(103) на УФ есть динамические списки, чего на ОФ нет

(105) отбор по колонке вроде уже есть

Если говорить о применении в условиях, где толстому клиенту хватает канала связи с сервером (это 98% моего трудового опыта), то

Обычные формы явно быстрее в работе пользователя и при разработке, исключая возьню с расположением и привязками элементов формы.
Функционально у управляемых форм конечно есть преимущества (например динамические списки) и их список конечно будет расти со временем.
Но писать код в обычных формах с модальностью и полной объектной моделью на клиенте - в разы приятнее и быстрее.

Ну с асинхами уже модальность не страшна

(103) ох ты госпади а у меня рубль есть и чо? Обязательно такой умник найдется. Я не спорю с очевидными +++, а пытаюсь донести что новое должно инкапсулировать все лучшее
что было ранее тогда это прогресс. А когда очевидно полезные и нужные вещи оголтело выкидываются предавая анафеме, а потом оп достаются из кладовки и оказывается технологичное
полезное и нужное, внезапно становятся любимой женой. Это ли прогресс? Это топтание на месте и движение в никуда.
Уж простите но ДС можно было и в ОФ сделать в конце концов нет там божественного таинства. Но вендор решил как решил. Имеет право

(109) ты попробуй асинхронно задать вопрос при закрытии управляемой формы, словишь подагру и нервный тик и потеряешь здоровый сон. Гарантирую!
Разрабы лавировали со совей асинхронностью лавировали да невылавировали

(108) >Но писать код в обычных формах с модальностью и полной объектной моделью на клиенте - в разы приятнее и быстрее.

Это пока у тебя однопользовательское по сути приложение с монопольным доступом к "разного специфического оборудования".
А вот когда у тебя сотни юзеров и разное оборудование надо между ними шарить и чтобы не было проблем с блокировками и прочим то тут вопрос что лучше.

(112) Как тут УФ помогут?

(113) Это не "УФ помогут".
При усложнении системы критичская точка смещается с интерфейса на бизнес-логику. И вот там-то архитектура управляемого приложения с подробным и прозрачным разделением на клиент-сервер дает значительный выигрыш. А вид форм, он так себе.

(106) На ОФ есть динамические списки, только без доп. плюшек.

(115) там вся фишка в произвольных запросах

(116) Это все равно, что сказать: вся фишка управляемых форм в отсутствии привязок.

(117) привязки есть, явных привязок нет

(112) при работе с промоборудованием нет таких задач. Даже ТСД не надо "шарить" между сотней пользователей, не говоря уже про какой-нибудь станок.

если же нужно раздавать получаемые со станка данные - с этим прекрасно справляются БД, а middleware, которое находится между станком и БД - обычно на 1С не пишут. Хотя, как мы видим, бывает такое.

(114) Что такое критическая точка и как она смещается?

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

Если-бы 1с пошло путем RDP (где на клиент гонится условно только картинка а не весь контекст), вот тогда ты был-бы прав, но 1с идет другим путем...

С точки зрения программирования куда удобнее когда весь код выполняется строго на сервере и нету никакого разделения контекста форм.

(122) > когда весь код выполняется строго на сервере
И затычки в уши, чтобы не слышать вопли о подключении торгового обрудования.

(123) все оборудование подключается через проброс портов

(124) Больные люди

(125) просто это надо сделать сразу на уровне драйвера устройства

(126) То есть, уже не одна 1С со своей платформой кому-то чем-то обязана. Это хорошо.

(122) Vaadin это не RDP внутри браузера. Вообще не так. Да логика на сервере, но браузер нативно это отрисовывает в скомпилированном виде то что отдаст ему платформа. Просто
от тебя спрятаны все эти кишки &нfсервер &наклиенте &насерверенаклиенте. Просто пишешь в условном ОФ окружении со всей полнотой доступа к данным, а дальше платформа сама делает всю магию.
И делает гораздо лучше чем стандартный 1с-к. На сайте вендора есть демки погляди как оно шуршит. Да может и не на мульт пользователей но для кровавого ентерпрайза
скорость работы очень приличная, и уж точно на голову обходит 1с-ное решение. Про типовые в демке я уже говорил. По логике которые супер заоптимизирвоанные тк от самой 1с уж они то точно знают как готовить...
Как говорится все познается в сравнении.

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

(128) любой вызов дергает сервер, даже чтобы посчитать 1+1. Конечно проще но вот лучше ли?

(130) кто сказал что там нет оптимизации по типам контекста, просто это делает платформа за тебя) привет не строгая типизация в 1с. Теперь понятно?

Пока внешний мир гоняет в html5  и webasm мы копошимся в куче говна, 1с отстала на целые эпохи, увы

(131) а кто сказал что есть? В фузине например нету

(0)Зависит от логики приложения. Если большинство вычислений должно быть на клиенте, то ОФ будут лучше и наоборот.

В общем подытоживая, пофигу, кто как хочет тот так и ....(ну вы поняли)

(135) но кто-то сказал, что должно быть по другому?

(136) Ну как же типа бэст-практик? Дорожные карты, и все такое.
В других то ЯП это типа не берите, а берите тока это, или это устарело и не поддерживается и все такое.

(137) хз... сколько себя помню, всегда на сменах релизов разработки происходили какие-то траблы большей или меньшей степени абсурда, не только в 1С, но и на любых других средах разработки.