Какие проблемы у SysOperationProgress?

[Logger]

Цитата:

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

Мое предположение, у меня и было. Ситуация: создание нескольких сотен заказов, создание закупки по ним (это все в компании 1), и создание продажи по ним (в компании 2). Обработка по продажам и закупкам счетов на оплату. Для перехода между компаниями - changecompany. Дык вот через раз Аксапта "путалась" в какой компании она разносит. Причем путалась на ровном месте (то есть в различных частях кода). Пока не "отключил" прогресс в классах обработки именно для этой операции. После этого - ни одной ошибки. Так что претензии не к самому прогрессу, а к связке его работы в рамках нескольких компаний.

Именно так !

У нас тоже была такая фигня. Причем глюк вносил прогресс в SalesFormLetter - PurchFormletter

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

[kashperuk]

Да-да. В тему вот эта тема: (простите тавтологию )
Глюки при обработке отборочной накладной

[Maxim Gorbunov]

Есть предположение (проверить не смог, так как не смог смоделировать ситуацию пока), что проблему решит изменение свойства SetCompany дизайна формы SysOperationProgress (SetCompany = No).

[Logger]

Цитата:

Сообщение от Maxim Gorbunov

Есть предположение (проверить не смог, так как не смог смоделировать ситуацию пока), что проблему решит изменение свойства SetCompany дизайна формы SysOperationProgress (SetCompany = No).

Знать бы еще как проверять.
А то у нас глюк воспоизводился, но от раза к разу (и что самое обидное - как правило на боевой ).
Не нашел подходящей последовательности действий для его гарантированного воспроизведения.

[sukhanchik]

Чисто теоретически - можно предположить - как можно проверить.
Откуда получается глюк? Начинается код, инициализируется форма SysOperationProgress (в компании aaa). Потом делается changecompany (bbb), потом исполняется долгий код, в котором происходит обновление "градусника". Это не каждая строка с вызовом incCount(). В этот момент активизируется форма. Аксапта (т.к. форма была вызвана в компании aaa) тут же переключает компанию с bbb на aaa. В это время продолжает исполняться код, который предназначен для компании bbb. Когда этот код завершается - то мы оказываемся в компании aaa и код продолжает работать правильно.

Т.е. по сути - что нужно сделать - это написать джоб, в котором:
1. Форма SysOperationProgress открывается до changecompany
2. В changecompany после incCount(), который перерисовывает форму нужно создать к примеру запись в таблице, у которой SaveDataPerCompany=Yes

А вообще - исходя из этой идеи - действительно стоит проверить версию Максима Горбунова

[AndyD]

Проблема не в форме, на которой бегут гаджики.
Проблема - в форме, которая активируется после закрытия формы прогресса (а в методе SalesFormLetter.progressKill() как раз происходит удаление формы гаджика).
Если на ней есть хоть один датасоурс и установлено свойство SetCompany=true, то при ее активации произойдет вызов Application.setDefaultCompany().

Помимо отказа от использования метода SysOperationProgress.reset() (который в конце концов вызывается в progressKill()), можно так же модифицировать его таким образом:

public void reset()
{
    ...
    // D.Andy -->
    DataAreaId  curDataArea = curExt();
    int         line;
    // D.Andy <--
    ;
    ...
    if (id == ownerId)
    // D.Andy -->
    {
        line = infolog.line();
    // D.Andy <--
        infolog.operationProgressClear();
    // D.Andy -->
        if (curDataArea != curExt())
        {
            appl.setDefaultCompany(curDataArea, false);
            infolog.cut(line, infolog.line());
        }
    }
    // D.Andy <--
}

Т.е. если произошло переключение компании в процессе удаления формы прогресса - то восстановить ее обратно (компанию).
После изменения необходимо будет сделать инкрементную компиляцию

PS По поводу формы SysOperationProgress.
А вы уверены, что она используется при работе класса SysOperationProgress?
Во всяком случае, если посмотреть метод setupForm() класса SysOperationProgressForm, то видно, что форма там создается на лету, без использования каких-либо объектов AOT.
PPS Если на форме нет датасорсов, то преключение компаний при ее активации не произойдет

[konopello]

Цитата:

Если на ней есть хоть один датасоурс и установлено свойство SetCompany=true, то при ее активации произойдет вызов Application.setDefaultCompany().

даааа... я в свое врямя этот глюк ели отловил.

[sukhanchik]

Цитата:

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

Проблема - в форме, которая активируется после закрытия формы прогресса

Дааа... Как говорится век живи - век учись...

[Logger]

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

Цитата:

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

Помимо отказа от использования метода SysOperationProgress.reset() (который в конце концов вызывается в progressKill()), можно так же модифицировать его таким образом: ...

К сожалению, данный баг может быть вызван не только прогресс баром. Я сталкивался с проблемами которые вызывают формы SysPrintPrinterProgress и SysPrintProgress

Например у нас есть форма salesTable на ней по кнопке запускается обработка в компании 1, которая делает changeCompany в компанию 2 и печатает там несколько документов. В момент печати первого документа отображается форма печати (какая-то из двух SysPrintPrinterProgress, SysPrintProgress) и после её закрытия фокус попадает в на форму salesTable (вызываются методы SysSetupFormRun.activate() и salesTable.activate() ) происходит переключение в исходную компанию 1 и последующие документы уже печатаются неправильно.

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

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

Либо ядро должно как-то связывать контекст выполнения кода и текущую компанию, так что если даже фокус перешел на вызвавшую форму (salesTable в моем примере) и произошло переключение в компанию 1, то при передаче управления обратно в функцию вызванную с формы, нужно переключать и текущую компанию обратно в компанию 2.

P.S.
Ax 3.0 KR3

[Logger]

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

Для этого делаем такие изменения :
1. Заводим где-нибудь статический метод

// pkoz 24.10.2009
static 
//client
server 
boolean GRD_changeCompanyForbidden(boolean _parm = false, boolean _flush = false)
{
//    SysGlobalCache      SysGlobalCache = infolog.globalCache();
    SysGlobalCache      SysGlobalCache = appl.globalCache();
    boolean             ret;
    int                 retI;
    ;
    retI = SysGlobalCache.get(funcName(), 0, 0);
    if (!prmIsDefault(_parm)) // пишем
    {
        if (_parm)
        {
            retI++;
        }
        else
        {
            retI--;
        }
        SysGlobalCache.set(funcName(), 0, retI);
    }

    if (retI < 0 || _flush)
    {
        SysGlobalCache.set(funcName(), 0, 0);
        return false;
    }

    if(retI > 0)
        return true;

    return false;

}

у себя я добавил его на класс SysSetupFormRun

2. Создаем класс для сброса настроек состоящий из одного метода main

// GRD_changeCompanyFix_pkoz // pkoz 24.10.2009
static void main(args _args)
{
    ;
    SysSetupFormRun::GRD_changeCompanyForbidden(false, true);
}

ставим его вызов в меню, например в "Сервис - Разрешить смену компаний". Вызов этого пункта будет отменять все запреты по переключению компаний.

3. Вносим изменение в метод \Classes\Application\setDefaultCompany

    SysGlobalCache cache = appl.globalCache();
    container   GRD_stack = xSession::xppCallStack(); // pkoz 24.10.2009
    if (//GRD_isPkoz() &&
        (
           conPeek(GRD_Stack, 3) == @"(C) \Classes\FormRun\activate" // в трехзвенке
        || conPeek(GRD_Stack, 3) ==     @"\Classes\FormRun\activate" // в двухзвенке
        )
        && SysSetupFormRun::GRD_changeCompanyForbidden()
       )
    {
        warning("Запрещено переключение между компаниями. Для исправления выберите Меню Сервис - Разрешить смену компаний");
        return false;
    }

    ret = super(_selectableDataArea);

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

SysSetupFormRun::GRD_changeCompanyForbidden(true);

после выполнения

SysSetupFormRun::GRD_changeCompanyForbidden(false);

теперь не будет переключения между компаниями. Можно не отключать окна прогресс бара, принтера и т.п.

Пункт 2 нужен если обработка прервалась и отмена запрета переключения не была вызвана (например по ошибке).

[ivas]

В АХ2012 появился баг: при обновлении прогрессбара спомощью incCount(), в случае если не задан тотал для первого ползунка, он падает в ошибку..

Пример:

static void Job_1(Args _args)
{
    SysOperationProgress pBar;
    
    int i;
    ;
    
    pBar = new SysOperationProgress();
    
    for (i = 1; i <= 100; i++)
    {
        pBar.setText(int2str(i));
        pBar.incCount();
        
        sleep(1000);
    }
}

ошибка живет тут:
\Classes\SysOperationProgressBase\updateTime

...
            r3 = totalValue.lookup(1)-progress;
...

необходимо добавить проверку на существование 1ого элемента

            if (totalValue.exists(1)) //fix
                r3 = totalValue.lookup(1)-progress;

[DTD]

После in place upgrade на AX2012 CU6 перестали заканчиваться прогрессбары.

Сами задачи заканчиваются а окно прогресбара остается со случайными показателями (но чаще все таки в конце, например 97/100).
Это на всех машинах, в разных приложениях, везде где есть прогресбары, включая tutorial_progress форму.

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

[gl00mie]

Если отладчиком не ловится, то что показывает трассировка? Если сравнить классы SysOperationProgress* из старого и нового приложения, есть какие-нить различия? Эти классы используют classFactory.globalCache() для хранения ссылки на SysOperationProgress - может, кэш перестал вычищаться? Хотя там вроде используется ObjectIdent. А выполнение бизнес-логики, показывающей градусник, идет в CIL? Если отключить выполнение в CIL, проблема остаётся?

[DTD]

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

Сравнивал, SYP на этих классах не поменялся в CU6. CIL отключен, eсли включить ничего не меняется.

Кэш - один из главных кандидатов, но я не знаю как эту версию проверить.
//Были проблемы с ним перед этим, например каким-то образом продолжало тянуть из кэша классы в SourceDocumentExtensionFactory после очистки кеша из меню (там вроде все возможные методы очистки обоих кэшев вызывает внутри)

Вторая предпологаемая причина - при апгрейде инсталлятор/чеклист поменял какие-то настройки в конфиг файлах/удалил длл или что-то в этом роде, но опять же как это систематически определить непонятно.

Трассировщик не запускал, попробую как доберусь до клиента.

[DTD]

Профайлером нашел, - похоже человеческий фактор. По неизвестной причине в процессе апгрейда был закомментирован вызов очистки формы прогрессбара.