Легкое поведение поля BlockImage в журналах

[coolibin]

Ax 3.0

Сценарий:

• Открываем форму любого журнала
• Запускаем из нее по кнопке любое диалоговое окно (например, какую-нибудь печать)
• Не закрывая диалоговое окно возвращаемся в грид на журнале
• Нажимаем Esc

С этого момента в поле "Используется" имеем все время картинку с буквами "AX", независимо от наличия или отсутствия блокировки.

Кто-нибудь с этим справился?

[Sada]

Бывало, но по моей вине (В написанном мной функционале). Это слетает фильтр я думаю на форме журналов.

[coolibin]

Цитата:

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

Бывало, но по моей вине (В написанном мной функционале). Это слетает фильтр я думаю на форме журналов.

Что за фильтр? И при чем здесь фильтр?

[Sada]

Не, наверна не в фильтрах дело. А вообще баг прикольный

[kashperuk]

Хм. Спасибо, интересный баг. В АХ 2009 иконка - не АХ, а какая-то другая, но все же появляется.

[ZVV]

Цитата:

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

Хм. Спасибо, интересный баг. В АХ 2009 иконка - не АХ, а какая-то другая, но все же появляется.

Не с id ли "0" картинка?

[petergunn]

Тестировал сценарий на DAX 4.0.

Похоже прослеживается общая закономерность воспроизведения bug'а в целом для display-методов при закрытиий формы по 'Esc' и условии что с текущей формы открыта (и не закрыта) другая форма в режиме ожидания закрытия посредством formRun.wait().

При этом слетают значения всех display-методов выведенных в активную форму.
Если display метод выводил не картинку то совсем не прикольный bug.

[kashperuk]

petergunn, а можно примеры, чтобы я не искал сам? Спасибо

[petergunn]

Цитата:

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

petergunn, а можно примеры, чтобы я не искал сам? Спасибо

Набросал простенькую форму для демонстрации. Характерное поведение проявляется на display и edit методах связанных с источником данных формы (не связанный с источником данных edit метод itemTypeUnbound нормально пережил эксперимент):

[AndyD]

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

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

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

public boolean canClose()
{
    boolean     ret;
    container   c;
    int         i;
    ;

    ret = super();
    c = xSession::xppCallStack();
    i = 1;
    while (i <= conLen(c))
    {
        if (typeof(conpeek(c, i)) == Types::String)
        {
            if (match(@"\\FormRun\\wait>", conpeek(c, i)))
            {
                ret = false;
                break;
            }
        }
        i++;
    }

    return ret;
}