Доброго времени суток!

Дано: УПП 1.3.38.4, платформа 8.2.19.106, клиент-сервер на MS SQL. Есть обработка на управляемых формах. Результатом ее работы является формирование дерева значений, в котором около 1100 строк верхнего уровня, плюс 2-4 уровня вложений. После того, как дерево сформировано, по нему делается очень затруднена навигация. То есть переход от строки к строке занимает где-то 3-4 секунды. Кроме того, задержка происходит и при переключении между вкладками самой обработки. Внимание, вопрос: с быстродействием можно как-то поиграться или стоит принять как данность, что УФ при обычном приложении будет себя так паскудно вести? Ибо тут же ЗУП 3.0 и БП 3.0 (платформа у них, правда, своя), там таких перекосов не наблюдается.

это называеться кривые руки

на управляемых формах ДЗ самый неуправляемый элемент

(1) И как же их выпрямить, позвольте полюбопытствовать?

(0) у тебя там при активизации строки серверный счетчик дергается?

(4) +1
что навешано на дерево?

(3) нам отседа не видно, что ты там на обработчики навешал

(6) Да ничего, в том-то и дело. Только дерево сформировалось, и начинается свистопляска. Чтобы со строки на строку перейти, приходится ждать. А разворачиваются уровни без проблем.

(7) какие колонки в строке? не вызов через три точки?

(7) количество подуровней не выводите?

так дерево значений могут быть не только в уф.
сферическая абстракция в виде неназываемой обработки на УФ с неизвестным содержанием, которая тормозит предположительно на обработке события в поле неизвестного типа ПриАктивизацииСтроки

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

В Бит-финанс в форме ввода бюджета такая же байда...
700 строк дерева 5-7 уровней... и все... их пересчет формул/значений тупо вешает сервер...

Разобрался, хоть от этого и не легче. Обработка не моя, поэтому не сразу верные вводные получились. По порядку. Вызова через точку нет. У дерева порядка 10 колонок, половина из которых имеют типы справочника номенклатуры, характеристики номенклатуры, единицы измерения, спецификации. Другая половина - числовой формат. (10) - совершенно верно. При детальном изучении оказалось, что ПриАктивизацииСтроки осуществляется отбор по соседней ТЗ с помощью ОтобратьСтроки. (11) Замер производительности показал, что на это ОтобратьСтроки уходит больше всего времени, но в любом случае не 3-4 секунды. Ну и отказаться от отбора никак нельзя, ибо ради этого все и задумывалось

(13) ну вот как я и говорил в (1)

Комментирование кода обработчика ПриАктивизацииСтроки напрочь снимает все тормоза. А заодно и нужный функционал )))

(14) В УАТ 2.0 ОтобратьСтроки работает на ура, причем с несколькими ТЗ, я поэтому и не обратил на это никакого внимания. Единственно, конфа полностью на УФ. Так что можно поспорить.

(13) Делать отбор не сразу, а с паузой скажем в 0,5 сек. Это позволит перемещаться по таблице, а при остановке на нужной сделает отбор.

при активизации принято в уф делать через обработку ожидания

(18) Я больше склоняюсь к использованию НайтиСтроки. Все-таки это уф в обычном приложении.

(16) вы наверно там проиндексировать забыли, поэтому отбор медленно работает.

(20) А разве тз индексируется? Я понимаю, реквизит в справочнике...

(21) ну, помните, работа с ТЗ в закрытие месяца шла часами. ПОтом сделали индексы, чтобы ускорить. Это было 10 лет назад. Или 20?

(22) Что-то не припоминаю. Может, ТЗ.Сортировать() ?

(23) ТЗ.Индексы

(24) А, вон про что! Просто у меня ТЗ - это табличная часть в обработке. И в нее сразу запрос выгружается. Попробую через промежуточную ТЗ, которую и проиндексирую.

(25) Не помогло ((

(25) а дин.список вместо ТЗ сделать?

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

(28) это почему это?

(0) УФ на Толстом клиенте, это как если запустить на ПК два толстых клиент, да и то будет работать быстрее :)

+(0) Хочешь скорости, то перепиши её на Обычную форму для толстого. :)
Можешь не оптимизировать, будет работать в разы быстрее

(29) см. (1)

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

(33) Там не ошибешься, поле одно только