Странное поведение при обновлении форм ах2009

[DmitryK]

Уважаемые господа, сталкивался ли кто с подобной проблемой? При нажатии F5 на формах заказы на покупку и заказы на продажу, курсор уходит на другую запись формы (произвольно). Кажется, что такое поведение началось после накатывания обновления до версии 5.0.1500.64.91 (заметили не сразу). Используется бразильский слой.

С уважением, Дмитрий.

[Ivanhoe]

Обновлялось что? Приложение, клиент, АОС? При сильном (уровня SP) несоответствии АОСа и клиента в 2009 было много разных глюков.

[DmitryK]

Обновили все, полное соответсвие по версии клиента и сервера. Ни каких других глюков замечено не было.

В принципе, кто нибудь сталкивался с подобным поведение АХ?

С уважением, Дмитрий.

[DmitryK]

Я так понимаю, что ни кто с подобным поведением системы не сталкивался и не может предложить как с этим бороться?

C уважением, Дмитрий.

[gl00mie]

Я так понимаю, по F5 выполняется DS.research(true), где true - параметр _retainPosition. Сохранение позиции осуществляется за счет запоминания индекса записи в выборке и последующего перехода к записи с тем же индексом, так что теоретически курсор может уходить на другую запись, если выборка изменилась между последним обновлением формы и нажатием F5. В любом случае, стоит, наверно, посмотреть, как ведут себя другие формы в аналогичных ситуациях, например, формы справочников, где набор записей достаточно стабилен в масштабах времени работы с формой.

[DmitryK]

Подобные проблемы есть только с формами Заказов на покупку/продажу. В обоих гридах (шапка, строки). Убрали все свои модификации этих форм, эффект остался. Возможно проблема в бразильской модификации. В российской аксапте ни кто подобного не наблюдал?

С уважением, Дмитрий.

[gl00mie]

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

[DmitryK]

Первоначально эффект заметили при использовании кнопки на строках покупки <Настройка> - налог. Курсор переходит на другую запись.

С уважением, Дмитрий.

[DmitryK]

public void automaticTotalDiscount()
{
    PurchTable localPurchTable;
    ;

    if(VendParameters::find().AutomaticTotalDiscount)
    {
        for (localPurchTable = purchTable_ds.getFirst(true) ? purchTable_ds.getFirst(true) : purchTable_ds.cursor(); localPurchTable; localPurchTable = purchTable_ds.getNext())
        {
            localPurchTable.updateFinalDisc();
        }
        purchTable_ds.reread();
        purchTable_ds.refresh();
        purchLine_ds.executeQuery();
    }
}

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

C уважением, Дмитрий.

[sparco]

Так вызывается

purchLine_ds.executeQuery()

что и приводит к таким действиям. Возможно можно дописать:
запомнить позицию с помощью

pos =  purchLine_ds.getPosition();

после executeQuery написать

purchLine_ds.setPosition( pos );

Или же аналогичные действия с SetRecord как вариант

[DmitryK]

Спасибо, Дим.

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

С уважением, Дмитрий.

[S.Kuskov]

Zitat:

Zitat von DmitryK

хотелось бы понять зачем это сделано?

Как это зачем. Метод updateFinalDisc изменяет строки закупки. Вот executeQuery их и "перерисовывает".

Другой вопрос, почему метод automaticTotalDiscount вызывается при простом обновлении записи по F5?

[DmitryK]

Сергей, не совсем так. Эффект есть при нажатии F5 и кнопки на строках покупки <Настройка> - налог. Пользователь хочет посмотреть налоги по строке, а смотрит не по той, что была выбрана (в этом случае всегда по первой). Подумалось, что проблема может быть вызвана одной причиной. Начали с налогов.

void  clicked()
{;
    element.automaticTotalDiscount();

    PurchTotals::showTaxLine(purchTable,purchLine);
}

Изменение курсора происходит в automaticTotalDiscount(), по выше описанной причине.

С уважением, Дмитрий.

[DmitryK]

Перекрыли executeQuery() , поставили точку останова, по F5 он вызывается.

С уважением, Дмитрий.

[S.Kuskov]

Zitat:

Zitat von DmitryK

Перекрыли executeQuery() , поставили точку останова, по F5 он вызывается.

Откуда? Что выше по стеку вызова?

[DmitryK]

Выше linkActive(). При вызове super() этого метода вызывается executeQuery()

С уважением, Дмитрий.

[S.Kuskov]

Вы на каком датасурсе перекрыли executeQuery() и на каком гриде жмёте F5?

[DmitryK]

PurchLine, нижний грид (строки)

С уважением, Дмитрий.

[DmitryK]

В форме PurchTable обнаружен интересный метод, где отлавливаются F5. В нем, вроде, нет ни чего наказуемого, но не очень понятно предназначение. Код метода не помечен разработчиком, напрмер /GBR.

public int task(int _taskId)
{
    int ret;
    int rowposition;
    #task
    ;

    if(_taskId == #taskFormRefreshMenu ||_taskId == #taskFormRefresh_F5 )
    {
        rowposition = this.objectSet().getPosition();
        ret = super(_taskId);
        this.objectSet().setPosition(rowposition);
    }
    else
        ret = super(_taskId);

    return ret;
}

Подняли пустую российскую axapta там этого метода нет. Судя по коду, вроде как, попытка исправить ситуацию возникающую по F5. Кто-нибудь может это прокомментировать?

C уважением, Дмитрий.

[S.Kuskov]

Фикс не срабатывает по-видимому, потому что загадочный вызов linkActive()->executeQuery() происходит не внутри super метода task(), а чуть позже.

Можно попробовать действия для запоминания и восстановления позиции перенести непосредственно в метод executeQuery, а в методе task() только устанавливать флаг о необходимости таких действий. После выполнения этих действий в методе executeQuery не забыть снять флаг.