[ANN] Tabax 0.1 -- панель задач для Axapta

[mazzy]

Цитата:

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

Может кто-нибудь проверить на медленной машине, тормозит ли

Я по-прежнему не понимаю зачем тебе extendedBy.
Поскольку вики-движок неадекватно относится к конструкции ++, привожу кусок кода здесь

static void Test_PluginLoad(Args _args)
{
    Object      element;
    TabaxPlugin plugin;
    int         i;

    DictClass   tabaxPluginClass = new DictClass(classnum(TabaxPlugin));

    for( i=0; i<tabaxPluginClass.implementsCnt(); ++i )
    {
        plugin = new SysDictClass(tabaxPluginClass.implements(i)).makeObject();
        plugin.tabax(element);
    }

}

PS Обрати внимание, что реализация через интерфейс дает проверку на этапе компиляции (вместо runtime) и при такой реализации работает intellisence.

[belugin]

Цитата:

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

tabaxPluginClass.implementsCnt

Это интерфейсы, реализуемые классом

[mazzy]

Цитата:

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

Это интерфейсы, реализуемые классом

вах. виноват.

[mazzy]

Цитата:

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

Это интерфейсы, реализуемые классом

тогда могу предложить глянуть на SysDictClass::getImplements()
но он также сводится к перебору всех классов

[belugin]

скачать

Новое (по сравнению с 0.2.x):

• Работает в Ax4 (картинки лежат в подпапке tabax.ax4 их надо переписать в "C:\Program Files\Microsoft Dynamics AX\40\Client\Share\Include\tabax")
• Можно переводить интерфейс (уже переведен на русский и испанский (by Manel Querol (Mkz) from http://www.TrucosAx.com))
• управление окнами
• настройка ширины табов (максимальное значение, минимальное и "все табы одного размера")
• Зачатки Plugin SDK (отдельный XPOшник)
• Иван Кашперук доработал функциональность открытия поля, теперь оно открывает и поле таблицы
• Авторазмер: табакс не дает себя уменьшить или увеличить

Предлагаю всем подумать на тему "что надо от табакса плагинам"...

[belugin]

Если вы поставите Tabax 0.3b8 и плагин AxPath, сможете открыть Tabax в AOT прям по ссылке из форума

Спасибо AndyD, Ивану и еще одному человеку, пожелавнему остаться неизвестным

[DocSerzh]

С разрешения Максима Белугина привожу часть переписки, чтобы четче осветить предложение :
DocSerzh
При позиционировании записи в "\Forms\Tabax\Methods\goMenuItemForm"
очень много времени занимает formRun.dataSource().findRecord(record).
Предлагается использовать formRun.args().lookupField() и formRun.args().lookupValue() для позиционирования.
belugin
У меня сомнения по поводу formRun.args().lookupField() и formRun.args().lookupValue().
Эти поля теоретически могут быть использованы кодом формы, и поэтому в каких-то случаях их изменение может нарушить работу чего-то ...
_____________________________________________________________

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

Вариант 1

void goMenuItemForm(MenuItemType _itemType, MenuItemName _itemName, RecID _recID)
{
    Args args=new Args();
    FormRun formRun ;
    Common record;
    TableID tableID;

    // Dcs 04.04.2007 СБРFI-200703_02 KC
    FormDataSource      fds             ;
    // Dcs 04.04.2007 СБРFI-200703_02 KC
;
    args.menuItemType(_itemType);
    args.menuItemName(_itemName);
    formRun = new MenuFunction(_itemName, _itemType).create(args);
    formRun.run();
    if (_recID && formRun.dataSourceCount())
    {
        tableID = formRun.dataSource().cursor().TableId;

        //+ Dcs 04.04.2007 СБРFI-200703_02 KC
        // orig
        //  record = SysDictTable::newTableId(tableID).makeRecord();
        //  select firstOnly record
        //      where record.recID==_recID;
        //  formRun.dataSource().findRecord(record);

        if( ! formRun.args().lookupField() )
        {
            formRun.args().lookupField( fieldname2id( TableId, 'RecId') );

            formRun.args().lookupValue( int2str( _recId ) )              ;

            fds = formRun.dataSource().cursor().dataSource();

            fds.executeQuery();
        }
        else
        {
            record = SysDictTable::newTableId(tableID).makeRecord();

            select firstOnly record
                where record.recID==_recID;

            formRun.dataSource().findRecord(record);
        }
        //- Dcs 04.04.2007 СБРFI-200703_02 KC
    }
    formRun.detach();
}

Вариант 2
или c восстановлением lookupField ( в принципе, можно и целиком аргументы )

void goMenuItemForm(MenuItemType _itemType, MenuItemName _itemName, RecID _recID)
{
    Args args=new Args();
    FormRun formRun ;
    Common record;
    TableID tableID;

    // Dcs 04.04.2007 СБРFI-200703_02 KC
    fieldId             fldId           ;
    FormDataSource      fds             ;
    // Dcs 04.04.2007 СБРFI-200703_02 KC
;
    args.menuItemType(_itemType);
    args.menuItemName(_itemName);
    formRun = new MenuFunction(_itemName, _itemType).create(args);
    formRun.run();
    if (_recID && formRun.dataSourceCount())
    {
        tableID = formRun.dataSource().cursor().TableId;

        //+ Dcs 04.04.2007 СБРFI-200703_02 KC
        // orig
        //  record = SysDictTable::newTableId(tableID).makeRecord();
        //  select firstOnly record
        //      where record.recID==_recID;
        //  formRun.dataSource().findRecord(record);

        fldId = formRun.args().lookupField()                         ;

        formRun.args().lookupField( fieldname2id( TableId, 'RecId') );

        formRun.args().lookupValue( int2str( _recId ) )              ;

        fds = formRun.dataSource().cursor().dataSource();

        fds.executeQuery();

        formRun.args().lookupField( fldId )             ;

        //- Dcs 04.04.2007 СБРFI-200703_02 KC
    }
    formRun.detach();
}

Пояснения :
Рассуждаем логически . После formRun.run(); все, что могло сломаться в форме - уже сломалось и без нашего вмешательства. Если args были заданы до run() и есть в коде упоминание на lookup методы и их анализ - можно восстанавливать args после позиционирования по lookupField.
В предложенных вариантах :
1 - Если в обработчике menuItem были заданы args - позиционируемся по findRecord.В противном случае - по lookupField
2 - Позиционируеся по lookupField. Восстанавливаем lookupField после позиционирования (или все аргументы...)

Узкое место - анализ lookupField в executeQuery...

Перелопатил свою appl - не нашел таких критичесикх мест... В принципе,они отсекаются вариантом 1.

Преимущества
Позиционирование в SalesTable из конца в начало по lookupField идет меньше секунды, по findRecord - 25 ....

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

Извините, если немного сумбурно.

[kashperuk]

Цитата:

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

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

Прежде всего, спасибо за то, что не остались просто " еще одному человеку, пожелавнему остаться неизвестным" Страна должна знать своих героев

Теперь по делу:
А почему во втором способе восстанавливается только lookupField, а lookupValue остается с RecId?

Думаю, на данном этапе первый вариант в самый раз.
Но, как шаг для дальнейшего улучшения, второй вариант очень даже ничего.
Почему бы Вам не поэкспериментировать какое-то время с первым вариантом, добавив вывод какого-то сообщения в случае, если наткнулись на форму, на которой указан lookupField?
Мне кажется, особенно учитывая, что форма вызывается новая, и args формируется здесь же, что по ветке с findRecord идти никогда не будет
Возможно и не прав, не проверял.
Насколько я понял, Максим говорит о другом опасении. О том, что существуют формы, у которых логика завязана на использование значений lookupValue. Но, ИМХО, это в основном лукап-формы. В остальных (переход к основной таблице, к примеру) формах врядли значение этого поля анализируется. Завтра поищу по АОТ, чтобы утверждать наверняка.

[AndyD]

А почему вы считаете, что по lookupField( ) по RecId будет искать правильно?

В случае с SalesTable будет работать корректно, потому что большему salesId будет соответствовать больший recId (пока не перевалили на отрицательные recId!).
А, к примеру, InventTable. Там сортировка идет по itemId, и далеко не всегда большему itemId соответствует больший recId. И таких примеров по AOT можно привести массу.

PS Хотя и с SalesTable не факт. Так как номер заказа формируется при создании новой записи , а recId присваивается при сохранении в базу данных, то вполне может оказаться, что кто-то начал создавать заказ позже, а сохранил раньше.

[belugin]

Цитата:

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

А почему вы считаете, что по lookupField( ) по RecId будет искать правильно?

Можно усложнить - найти индекс по которому отсортирован дс, проверить уникальный ли он, проверить состоит ли он из 1 поля и только в ежэтом случае лукапить. Иначе скатываться к тормозному варианту

[AndyD]

Тогда надо формировать строку axpath опираясь не на recId, а на поля уникального индекса (если он есть, опять же).
А в случае recId корректнее все-таки поиск перебором.

[belugin]

Цитата:

Тогда надо формировать строку axpath опираясь не на recId, а на поля уникального индекса (если он есть, опять же).
А в случае recId корректнее все-таки поиск перебором.

Я имел ввиду следующее: если индекс по которому отсортирован дс уникален и состоит из 1 поля, то:

• выбрать запись по RecID селектом
• лукапнуть ее в дс по индексу

[belugin]

записал в туду пожелания и ошибки

[DocSerzh]

Цитата:

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

Прежде всего, спасибо за то, что не остались просто " еще одному человеку, пожелавнему остаться неизвестным" Страна должна знать своих героев
.

Как то неудачно засветился с комментариями...хм

Цитата:

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

Теперь по делу:
А почему во втором способе восстанавливается только lookupField, а lookupValue остается с RecId?
.

После executeQuery lookupValue сбрасывается (или после super() в нем, перекрытом).

Цитата:

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

Мне кажется, особенно учитывая, что форма вызывается новая, и args формируется здесь же, что по ветке с findRecord идти никогда не будет
.

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

Цитата:

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

Завтра поищу по АОТ, чтобы утверждать наверняка.
.

Проверил у себя [ сильно перелопаченный retail от коруса] :
В основном Lookup используются в init'e для анализа включать фильтры , накладываемые на форме, или нет...
Единственна критическая форма - Addresses , с ипользованием linkActivate в случае открытия из vendTable...
К сожалению, нет сейчас appl под рукой - по памяти....

Цитата:

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

А почему вы считаете, что по lookupField( ) по RecId будет искать правильно?
В случае с SalesTable будет работать корректно, потому что большему salesId будет соответствовать больший recId (пока не перевалили на отрицательные recId!).
А, к примеру, InventTable. Там сортировка идет по itemId, и далеко не всегда большему itemId соответствует больший recId. И таких примеров по AOT можно привести массу
.

Насколько я понимаю, позиционирование идет самим движком, уже в выбранном и отсортированном ds [?]..Не вижу причин [но проверю обязательно - есть такая большая DB с отрицательными recId] почему бы ему (движку) искать не корректно... или имелось ввиду время позиционирования?

Цитата:

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

Можно усложнить - найти индекс по которому отсортирован дс, проверить уникальный ли он, проверить состоит ли он из 1 поля и только в ежэтом случае лукапить. Иначе скатываться к тормозному варианту
.

Эксперементировал на эту тему до знакомства с tabax...Положительных результатов не получил - как то странно работают объекты AOT, отвечающие за анализ PrimaryKey и уникальность индекса.. ( нет appl под рукой - иначе бы запостил результаты и код job'a, который меня смутил)... Поэтому и остановился на варианте ,используемом в tabax.

Цитата:

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

Тогда надо формировать строку axpath опираясь не на recId, а на поля уникального индекса (если он есть, опять же).
А в случае recId корректнее все-таки поиск перебором.
.

В случае НЕуникальности RecId?

[belugin]

Есть вот такие штуки:

SysDictTable/getIndexIdsOfUniqueOneFieldIndexes

Global/record2DynaKey

[kashperuk]

Гы. Работает. Обе ссылочки открыли код нормально.
Правда вторая повтыкала еще секунд 5 или чуть больше перед активацией окна. Не сразу таймер короче сработал.

[DocSerzh]

Цитата:

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

Есть вот такие штуки:

SysDictTable/getIndexIdsOfUniqueOneFieldIndexes

Global/record2DynaKey

Интересно, не знал.Спасибо. Действительно, много времени потратил впустую...

[AndyD]

Цитата:

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

Насколько я понимаю, позиционирование идет самим движком, уже в выбранном и отсортированном ds [?]..Не вижу причин [но проверю обязательно - есть такая большая DB с отрицательными recId] почему бы ему (движку) искать не корректно... или имелось ввиду время позиционирования?

Нет. Не верно.
При лукапе на сервер отправляется запрос вида

select *
from TableName
where recid >= recIdValue
order by [- ,     ]

После этого курсор на форме позиционируется на первую полученную запись.
Если порядок сортировки по полям не будет совпадать с порядком сортировки по recId, то запись отпозиционируется неверно

[DocSerzh]

Цитата:

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

Нет. Не верно.
При лукапе на сервер отправляется запрос вида

select *
from TableName
where recid >= recIdValue
order by [- ,     ]

После этого курсор на форме позиционируется на первую полученную запись.
Если порядок сортировки по полям не будет совпадать с порядком сортировки по recId, то запись отпозиционируется неверно

Спасибо за проверку, нет возможности сечас проверить самому...

[gl00mie]

Цитата:

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

При лукапе на сервер отправляется запрос вида

select * from TableName where recid >= recIdValue
order by [- ,     ]

После этого курсор на форме позиционируется на первую полученную запись.Если порядок сортировки по полям не будет совпадать с порядком сортировки по recId, то запись отпозиционируется неверно

Кстати, да. Я «по просьбам трудящихся» переделал сортировку в формах закупок и заказов - сделал сортировку по ожидаемой дате поставки, в результате jumpRef из журнала накладных стал попадать не туда