УПП и управляемые формы. #792319

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ну вот как я и говорил в

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

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

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

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

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

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

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

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

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

ТЗ.Индексы

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

Не помогло ((

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

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

это почему это?

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

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

см.

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

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