Как гарантированно уронить клиента AX2009

[ta_and]

Выделяем пару менюИтемов, и тыкаем в свойство Object

Ахарта не вылетает? - Руки кривые!!! )

[ta_and]

Как гарантированно уронить клиента AX2009

1. Создаем Query
2. В источники данных кидаем какую-нибудь табличку.
3. В добавленной табличке в связанные источники данных кидаем связанную табличку
4. Устанавливаем Relations = Yes у добавленной таблички
5. Идем в ветку Relations
6. Правой кнопкой мыши - Копировать

Ахарта не вылетает? - Руки кривые!!! )

[user_ax]

В 2012 исправили или такие же баги ?

[gl00mie]

В 2012 при выделении нескольких пунктов меню не показывается свойство Object, а при попытке копирования relation'а в запросе, созданного по Relations = Yes, ничего не происходит.

[user_ax]

Цитата:

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

В 2012 при выделении нескольких пунктов меню не показывается свойство Object, а при попытке копирования relation'а в запросе, созданного по Relations = Yes, ничего не происходит.

Значит, поправили. Это радует.

[ta_and]

Как гарантированно уронить клиента AX2009

1. Берем метод таблицы.
2. Перетаскиваем этот метод с нажатым Ctrl в методы другой таблицы.
3. Удаляем перетащеный метод в исходной таблице
4. Сохраняем.

Ахарта не вылетает? - Руки кривые!!! )

[ta_and]

Про драг-н-дроп в Ах еще много можно было бы написать... времени жалко.

[d_alexe]

Цитата:

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

Выделяем пару менюИтемов, и тыкаем в свойство Object

Ахарта не вылетает? - Руки кривые!!! )

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

остальное да работает

application Dax 2009 5.0.1500.2985

[S.Kuskov]

При изменении свойств нескольким выделенным объектам заметил такую особенность. Если сначала открыть окно свойств а затем выделить несколько элементов, то с большой вероятностью будет ошибка. А если сначала выделить объекты и уже потом открыть окно свойств, то скорее всего все получится.

[Romb]

На AX 2009 5.0.1500.3761 все стабильно! Выделяешь - вылетаешь!
Работает баг!

[ta_and]

Как гарантированно уронить клиента AX2009

1. создаем джобик

    Map                 map;
    MapEnumerator       me;
    ;

    map = new Map(Types::String, Types::void);
    map.insert("1", null);
    map.insert("2", null);
    map.insert("3", null);

    me    = map.getEnumerator();
    while (me.moveNext())
    {
        if (me.currentKey() == "2")
        {
            map.remove(me.currentKey());
        }
        info(me.currentKey());
    }

2. запускаем.

Ахарта не вылетает? - Руки кривые!!! )

PS не надо мне говорить, что я делаю неправильно. я знаю, что я делаю неправильно. Но от этого ахарта не должна ложиться насмерть... имхо.

[gl00mie]

Ну... это называется "прострелить себе ногу" - с таким же успехом можно разыменовывать null. Оно как бы общеизвестно, что в цикле с использованием enumerator'ов нельзя менять соотв. коллекцию, а если очень хочется, то надо использовать iterator'ы. Вообще же рекомендуется все желаемые изменения сохранять где-нить сбоку и накатывать на коллекцию после завершения прохода по ней enumerator'ом. См. также Changes to the Collection Classes in Dynamics AX 2012

[ta_and]

Цитата:

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

Ну... это называется "прострелить себе ногу"

Я от системы ожидаю адекватного поведения на мои ошибки.
В приведенной документации (кстати по 2012) закономерно говорится, что в таких случаях будет выдано исключение. На этапе компиляции или рантайм - даже не важно.
2009 просто падает. безответно.
Это очень хорошо в тестовом примере.
А если эта хрень написана в 900 строках кода с вызовами разных побочных методов и дополнительных циклов, то искать эту ошибку очень весело.
Ванька-встанька получается.

[ax_mct]

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

То есть знать такие вирусы просто необходимо даже если сам так делать не будешь. Я уверен что процентов 80% как минимум моих коллег о таком и не подозревают.
Best Practices тоже штука общеизвестная но такое впечатление что всем незнакомая

[gl00mie]

Цитата:

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

Я от системы ожидаю адекватного поведения на мои ошибки.

У любой системы есть способы ее использования, на которые она рассчитана, и способы, на которые она не рассчитана. Enumerator'ы коллекций не рассчитаны на то, что по ходу работы с ними коллекция будет изменяться. Под отладчиком видно, что изменение коллекции приводит к тому, что enumerator начинает ссылаться на "левый" кусок памяти (в отладчике виден мусор вместо текущего значения). Т.е. изменение коллекции "сбивает" некий указатель, который используется enumerator'ом, и в следующий раз он обращается к области памяти, которая не имеет к коллекции никакого отношения. Я лично подозреваю, что "дураконезащищенность" enumerator'ов была реализована намеренно для повышения производительности их работы. Про эту их особенность просто надо знать - подобно тому, как надо знать про особенности клиент-серверного взаимодействия и то, что некоторые вызовы обрабатываются локально, а некоторые - путешествуют по сети до другого компа и обратно.

Цитата:

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

В приведенной документации (кстати по 2012) закономерно говорится, что в таких случаях будет выдано исключение.

В приведенной документации говорится, что CLR изначально не позволяла менять коллекцию при одновременной работе с enumerator'ом, и из-за этого в AX 2012 внесли аналогичные изменения в ядро, чтобы коллекции вели себя одинаково при выполнении кода Х++ как в интерпретаторе, так и в CIL. Никто там не говорит, что всем надоели программистские ошибки, и поэтому работу с enumerator'ами ужесточили.

Цитата:

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

А если эта хрень написана в 900 строках кода с вызовами разных побочных методов и дополнительных циклов, то искать эту ошибку очень весело.

В стандартном приложении той же 2009-й такой "хрени" просто нет: там либо используется enumerator, и коллекция внутри цикла работы с ним не меняется, либо используется iterator, и коллекция внутри цикла работы с ним может меняться, а может и не меняться (часть совсем legacy-кода, видать, написана, когда enumerator'ов в ядре еще не было).

[kashperuk]

Ну, тут сколько не спорь, а приложение не должно падать при любом раскладе, даже если это не описано в документации. Должно красиво выдавать какое-нибудь умное сообщение и тогда уже падать .

[ta_and]

Как гарантированно уронить клиента AX2009

Берем любой Query с двумя связанными таблицами,
с установленным свойством relations=Yes
у которых связь идет по двум полям.
Выделяем связи.
Нажимаем Ctrl+C

Ахарта не вылетает? - Руки кривые!!!

[ta_and]

Не совсем в тему...
Но тоже интересно.
Найди ошибку.

    #DEFINE.FieldListAX(@"
             CustAccount
        ,    NameAlias
        ,    RouteId
        ,    CityDescription
        ,    CustGroupId
        ,    CustClassificationId
        ,    MainContactWorkerName
        ,    CreditMax
        ,    NumOfDays
        ,    CustDisc
        ,    DefaultAgreementId
        ,    DlvMode
        ")

[S.Kuskov]

Цитата:

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

Найди ошибку.

    #localmacro.FieldListAX
        @"
             CustAccount
        ,    NameAlias
        ,    RouteId
        ,    CityDescription
        ,    CustGroupId
        ,    CustClassificationId
        ,    MainContactWorkerName
        ,    CreditMax
        ,    NumOfDays
        ,    CustDisc
        ,    DefaultAgreementId
        ,    DlvMode
        "
    #endmacro

Так же смотри AX2009. Не сохраняется Job