Как глобально отключить автоопределение ширины столбца = autoSizeColumns(false) ?

[mazzy]

Цитата:

Сообщение от Logger

Совсем не обязательно. Код на sysSetupFormRun.init() можно сделать совсем хитрым, чтобы реагировал только на определенные формы и нужные гриды доставал из дизайна сразу по имени, не перебирая всех контролов. Тогда форма не переезжает на usr-слой.

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

в общем, про sysSetupFormRun я помню.
на всякий случай: formdigger программистами заказчика установлен, освоен и используется (спасибо автору, DSPIC)

[mazzy]

Цитата:

Сообщение от db

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

Да. Но я очень боюсь потери производительности при открытии форм при обработке контролов за счет обработки в SysSetupFormRun (особенно на маломощных компах. а такие есть). пусть уж лучше комп время тратит на определение ширины колонок, нежели на перебор контролов, чтобы отключить автоопределение ширины колонок.

кроме того, боюсь побочных эффектов из-за работы SysSetupFormRun (хотя formdigger стоит и не жужжит).

поэтому я предполагал, что буду изменять метод init и свойство autodeclaration во всех формах, которые потенциально могут быть медленными из-за большого количества записей. Так придется менять меньше форм, чем "все формы". но все равно очень много

[db]

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

[mazzy]

вот-вот.
об этом и речь - шило на мыло.

поэтому и спросил в надежде на возможные варианты.


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

[db]

Цитата:

Сообщение от mazzy

вот-вот.
об этом и речь - шило на мыло.

поэтому и спросил в надежде на возможные варианты.


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

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

[Logger]

Цитата:

Сообщение от db

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

Внимательнее читайте сообщения !

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

[gl00mie]

Цитата:

Сообщение от db

Ну в общем тоже сделал.

private void autoSizeColumns(boolean _autoSizeColumns)
{
    void traverse(Object _parent)
    {
        // ...
    }
    traverse(this.design());
}

Такие велосипеды уже давно изобретены - см. Итератор с поддержкой методов обратного вызова для обработки контролов на форме

Цитата:

Сообщение от mazzy

Но я очень боюсь потери производительности при открытии форм при обработке контролов за счет обработки в SysSetupFormRun (особенно на маломощных компах. а такие есть).

Нет ее - этой потери производительности Если есть сомнения, можно код перебора контролов обрамить следующим образом и посмотреть, сколько времени потратится:

UtcDateTime     dateTimeStart;
;
dateTimeStart = DateTimeUtil::utcNow();
// лопатим контролы...
info( strfmt( @"%1 мс", DateTimeUtil::getDifference( DateTimeUtil::utcNow(), dateTimeStart ) * 10 ) );

Цитата:

Сообщение от mazzy

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

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

Цитата:

Сообщение от mazzy

поэтому я предполагал, что буду изменять метод init и свойство autodeclaration во всех формах, которые потенциально могут быть медленными из-за большого количества записей. Так придется менять меньше форм, чем "все формы". но все равно очень много

Тю!..

Цитата:

Сообщение от mazzy

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

Какой еще switch?.. В общем, есть такой способ решения этой задачи (во многом схожий с тем, что уже обсуждалось):

• в SysSetupFormRun делаются обработчики, вызываемые до и после инициализации формы (вызова super() в init()) - это позволяет не замусоривать своим кодом перекрытый init() и легко переносить потом модификации;
• в SysSetupFormRun заводится метод, который возвращает множество названий форм, где надо перебить указанное свойство гридов. Во множество прописываются наиболее "тяжелые" формы с фиговой тучей полей в гридах (тормозит ведь именно на количестве полей, а не числе записей, ну еще на display-методах), соотв. добавить туда новую форму можно одной строкой кода. Для оптимизации множество кэшируется в GlobalCache;
• В обработчике, вызываемом в SysSetupFormRun после инициализации формы, дергается метод, перебивающий свойствов гридов, если текущая форма - одна из множества.

Таким образом, получается минимум легко переносимых и настраиваемых кастомизаций.
\Classes\SysSetupFormRun\DEV_getSetOfFormNames2TweakGrid

// возвращает множество названий форм, на Grid'ах которых нужно отключить austoSizeColumns
protected Set DEV_getSetOfFormNames2TweakGrid()
{
    Set ret = infolog.globalCache().get( classstr(SysSetupFormRun), funcname(), null );
    ;
    if (!(  ret
        &&  ret.typeId() == Types::String
       ))
    {
        ret = new Set( Types::String );
        // собственно здесь нужно перечислить названия форм, которые нужно автоматом "допиливать" при старте
        ret.add( formstr(OfficialsTable_RU) );
        ret.add( formstr(PurchTable) );
        ret.add( formstr(SalesTable) );

        // запоминаем множество в globalCache, чтоб не создавать каждый раз
        infolog.globalCache().set( classstr(SysSetupFormRun), funcname(), ret );
    }
    return ret;
}

\Classes\SysSetupFormRun\DEV_initDesignPost - тут используется итератор из этой темы

// дополнительное допиливание дизайна формы после инициализации
protected void DEV_initDesignPost()
{
//  UtcDateTime     dateTimeStart;
    identifiername  formName = this.name();
    ;
    if (this.DEV_getSetOfFormNames2TweakGrid().in( formName ))
    {
//      dateTimeStart = DateTimeUtil::utcNow();
        DEV_iterateThroughFormControls( this.design(), null, staticmethodstr(DEV_FormHelpers, setGridAutoSizeColumnsOff), DEV_FormHelpers::addGridCtrlId2Set() );
//      info( strfmt( @"%1 мс", DateTimeUtil::getDifference( DateTimeUtil::utcNow(), dateTimeStart ) * 10 ) );
    }
}

\Classes\SysSetupFormRun\DEV_initDesignPre

// дополнительное допиливание дизайна формы до инициализации
protected void DEV_initDesignPre()
{
    // ACHTUNG! Эта модификация к проблеме grid'ов никакого отношения не имеет!
    // опционально вертаем окна взад в рамки основного окна клиента (точнее, текущего workspace'а)
    if (    this.form().design().windowType()                       == FormWindowType::Standard
        &&  DEV_UserInfoParameters::find().DefaultFormWindowType    == DEV_DefaultFormWindowType::Workspace
       )
    {
        this.form().design().windowType( FormWindowType::Workspace );
    }
}

\Classes\SysSetupFormRun\init

public void init()
{
    // <GEEU>
    this.raiseEvent_W(methodstr(FormRunListener_W, beforeInit));
    // </GEEU>
    this.DEV_initDesignPre();                   // наши модификации
    super();
    SysSecurityFormSetup::loadSecurity(this);
    this.dimensionFieldCtrls();
    this.inventStorageDimFieldCtrls();

    if (this.isWorkflowEnabled())
    {
        workflowControls = SysWorkflowFormControls::construct(this);
        workflowControls.initControls();
    }
    this.DEV_initDesignPost();                  // наши модификации
    // <GEEU>
    this.raiseEvent_W(methodstr(FormRunListener_W, afterInit));
    // </GEEU>
}

[db]

Цитата:

Сообщение от Logger

Внимательнее читайте сообщения !

ок, постараюсь но согласитесь написано слегка неоднознано

Цитата:

Сообщение от gl00mie

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

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

[gl00mie]

Цитата:

Сообщение от db

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

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

Если бы в Х++ была встроенная поддержка делегатов, не требующая разного рода костылей и игр с механизмами отражения, думаю, многи задачи решались бы с куда меньшими накладными расходами на кодирование и/или объемом copy-paste'а.

[mazzy]

Цитата:

Сообщение от gl00mie

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

задал вопрос в исходной ветке: Итератор с поддержкой методов обратного вызова для обработки контролов на форме

[Geo]

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

[gl00mie]

У меня лично сложилось мнение, что дело не столько в количестве записей в таблице, сколько в количестве полей, отображаемых в Grid'е, и, если в нем есть поля на базе display/edit-методов, в скорости обсчета этих методов (которая, впрочем, может коррелировать с количеством записей в той или иной таблице ).

[Ivanhoe]

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

[mazzy]

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

Цитата:

Сообщение от Geo

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

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

Конечно же, автоопределение не зависит от скролбара. По-моему и проблемы со скорлбаром, и проблемы с автоопределением вызваны одной и той же причиной.

[Geo]

Чего-то я ничего не вижу
Это свойство грида - autoSizeColumns? Не могу такого найти...

[mazzy]

Цитата:

Сообщение от Geo

Чего-то я ничего не вижу
Это свойство грида - autoSizeColumns? Не могу такого найти...

это runtime-свойство.

[gl00mie]

Цитата:

Сообщение от mazzy

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

Не понял эту фразу... В стандартном варианте на всех гридах, включая те, что на форме обозревателя, автоопределение ширины столбца включено. Для обозревателя, на ряду с другими формами, его можно отключить. Я сперва засомневался и попытался, было, приделать в SysSetupFormRun вывод значения свойства autoSizeColumns() для всех открываемых форм (опять же, с помощью итератора ), но тут обнаружил, что соотв. метод на FormGridControl не возвращает текущее значение свойства, а лишь позволяет устанавливать его. К слову, если пользоваться предложенным мной вариантом, то после изменения перечня форм в методе SysSetupFormRun надо перезапускать клиента либо очищать закэшированное в GlobalCache множество названий форм, потому что произведенные изменения в коде не возымеют действия, пока есть закэшированное множество.
Возвращаясь к обозревателю, можно попробовать на двух таблицах: CustTrans и CustTransIdRef. Записей там должно быть одинаковое количество, при этом в CustTrans, в моем случае, более 100 полей, включая системные, в то время как в CustTransIdRef их всего 5. Впрочем, тут сложно отделить замедление, связанное с автоопределением ширины столбцов, от общего замедления, связанного с обработкой большего числа полей обозревателем. Во всяком случае, я лично отчетливо вижу разницу во времени открытия обозревателя для таблиц CustTrans и CustTransIdRef, однако, отключение автоопределения ширины столбцов для grid'ов формы обозревателя таблиц в моем случае не дает сколь-нибудь заметного ускорения.

Цитата:

Сообщение от mazzy

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

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

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

Form 'SalesTable', autoSizeColumns( false )
5159 ticks average per 10 times
Form 'SalesTable', autoSizeColumns( true )
6795 ticks average per 10 times
Form 'SysTableBrowser' for LedgerJournalTrans, autoSizeColumns( false )
2479 ticks average per 10 times
Form 'SysTableBrowser' for LedgerJournalTrans, autoSizeColumns( true )
2417 ticks average per 10 times

Для обозревателя таблицы результат несколько неожиданный: автоопределение ширины колонок хоть чуть-чуть, но ускоряет, а не замедляет его открытие. Я гонял тест много раз - результат для обозревателя всегда повторялся. NB! Некоторые формы требуют указания параметров для успешного запуска, и их надо запускать через специальный пункт меню. Класс на это не заточен, кому надо - допилите.

[mazzy]

Цитата:

Сообщение от gl00mie

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

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

Цитата:

Сообщение от gl00mie

У меня получились такие тестовые результаты:

отличный подход! респект.
я всего-лишь на глаз мерял. при выключенной автоширине значительно быстрее.
но завтра замеряю.

эксперимент - критерий истины.

[Daiver]

Цитата:

Сообщение от db

Ну в общем тоже сделал.
Во вложении измененный SysSetupFormRun из RU5
....
Малость (не более 0,1 сек) притормаживает открытие формы в зависимости от количества элементов на ней.

Если использовать данную модификацию, действительно немного быстрее открывается форма. Но попробуйте теперь создать запись например в Управление запасами\Журналы\Проводки по номенклатуре\Проводка, что при этом происходит со столбцами грида и их заголовками? Все успешно разъезжается. Не красиво как-то получается. Такое впечатление что для создаваемой строки отрабатывает свойство autoSizeColumns(true).
Если отредактировать ширину какого либо столбца руками, чтобы система запомнила настройки формы, то такого глюка не возникает.

[Logger]

Странно.
По идее эта опция на грид целиком должна влиять.