Сброс фильтра в KR3 по Ctrl-N

[egorych]

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

[AndyD]

В KR2 то-же самое.
Могу предложить такое решение.
В декларацию класса SysSetupFormRun добавить флаг

public class SysSetupFormRun extends FormRun
{
    boolean newRecordMode;
#if.never
    #define.CurrentVersion(1)
    #localmacro.CurrentList
    #endmacro
#endif
}

В методе task() этого класса вместо вызова super() вставить такой код

    ...
    if (_p1 == 260/* #taskNew*/)
        newRecordMode = true;
    if (newRecordMode && _p1 == 2840)
        ret = 1;
    else
        ret = super(_p1);
    if (_p1 == 260 /* #taskNew*/)
        newRecordMode = false;
    ...

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

[gl00mie]

Цитата:

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

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

Цитата:

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

В KR2 то-же самое.

К слову, заметил интересную особенность: если новую запись добавлять не по Ctrl-N, а по <стрелка вниз>, то фильтр не сбрасывается и даже используется для заполнения полей новой записи - во всяком случае, в KR2.

[AndyD]

Угу.
По стрелке вниз другой taskId приходит (1282), соответственно, и обработка другая происходит.

[gl00mie]

Цитата:

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

Угу. По стрелке вниз другой taskId приходит (1282), соответственно, и обработка другая происходит.

Ну, может, тогда так и задумано? В любом случае, если накладывается фильтр (а не просто производится поиск), то записи, удовлетворяющие фильтру, есть, и тогда ничто не мешает нажать Ctrl-End + стрелка_вниз, чтобы избежать сброса фильтра.

PS. Судя по моим закладкам, все это уже обсуждалось, выводы сделаны были те же
сброс фильтров на формах в KR3

[AndyD]

Ну, я не имею доступ на партнерские ресурсы, но здесь и ниже Андре пишет, что MBS обещала это исправить, так что, скорее всего, бага

Кстати, а чем поиск от фильтра отличается?

[gl00mie]

Цитата:

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

Ну, я не имею доступ на партнерские ресурсы, но здесь и ниже Андре пишет, что MBS обещала это исправить, так что, скорее всего, бага

Мда, к сожалению, в списке выпущенных hot fix'ов ничего такого пока не упоминается

Цитата:

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

Кстати, а чем поиск от фильтра отличается?

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

[AndyD]

Ну, это в кернеле надо править, а sp6, к примеру, содержит в себе kr3, который от ошибки не избавлен. Так что надо kr4 ждать
А по поводу поиска - так он тоже в конечном счете приводит к наложению фильтра на датасоурс. Так что разделять их не стоит. Имхо.

[Logger]

Цитата:

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

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

в каком то из роллапов было указано на глюк когда при создании записи на форме с установленным фильтром могли сгенериться одинаковые LineNum.
Типа роллап это исправил.

Возможно эта багофича лечила именно этот глюк. Перед созданием записи сбрасывала фильтр, чтобы гарантировано не мог воспроизвестись баг с одинаковыми LineNum

[gl00mie]

Цитата:

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

в каком то из роллапов было указано на глюк когда при создании записи на форме с установленным фильтром могли сгенериться одинаковые LineNum. Типа роллап это исправил. Возможно эта багофича лечила именно этот глюк. Перед созданием записи сбрасывала фильтр, чтобы гарантировано не мог воспроизвестись баг с одинаковыми LineNum

Точно, это как раз было в KR2 fixlist:

Цитата:

Request No. 13800
KB 912788
Short Desc Filtering on any form causes duplicate linenums
Problem On the form where lines are numbered it is possible to create duplicate values in the line number field. These duplicate line numbers prevent posting to the journal.
Cause This problem may occur when the journal form is filtered by line number.
Solution Remove the filter when adding a new line between existing lines on the sales order.

Так что по ходу ждать исправления такого поведения бесполезно...
Вместо того, чтобы сделать уникальные индексы [JournalId, LineNum] на строках журналов, сделали сброс пользовательского фильтра везде

[Logger]

Лучше сделать так

    if (_p1 == 260/* #taskNew*/)
        SysSetupFormRun::GRD_NewRecordMode(this.hWnd(), true);
    if (_p1 == 2840 && SysSetupFormRun::GRD_NewRecordMode(this.hWnd()))
        ret = 1;
    else
        ret = super(_p1);
    if (_p1 == 260 /* #taskNew*/)
        SysSetupFormRun::GRD_NewRecordMode(this.hWnd(), false);

и еще добавить вот такой метод

  // pkoz 27.07.2007
static boolean GRD_NewRecordMode(int    _hwnd, boolean _parm = false)
{
    SysGlobalCache      SysGlobalCache = infolog.globalCache();
    boolean             ret;
    ;
    if (prmIsDefault(_parm)) // читаем
    {
        ret = SysGlobalCache.get(funcName(), _hWnd, false);
    }
    else
    {
        if (_parm)
        {
            SysGlobalCache.set(funcName(), _hWnd, _parm);
        }
        else
        {
            SysGlobalCache.remove(funcName(), _hWnd); // значение false не кладем
            // а просто чистим кеш - чтобы не флудить его ненужными значениями - все равно
            // hwnd почти всегда новый выделяется
        }
        ret = _parm;
    }
    return ret;
}

При таком подходе нет ошибок выполнения при фильтрации в лукапах.

[Logger]

Цитата:

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

Точно, это как раз было в KR2 fixlist:
Так что по ходу ждать исправления такого поведения бесполезно...
Вместо того, чтобы сделать уникальные индексы [JournalId, LineNum] на строках журналов, сделали сброс пользовательского фильтра везде

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