Плагин к Tabax DEV_RegisterChange

[KingPeas]

Делалось достаточно давно еще когда работал на прежнем месте работы изначально под 3.0, потом переделывал под 4.0. Для работы необходим Tabax. Инструкцию, иконки и сам проект прикладываю в архиве (пока к сожалению версия только под 4).
Единственное что требуется для вмешательство в систему дописать в Editor один метод и дополнить один существующий. Свой исключил из проекта, поскольку у нас много мусора в нем.

Создаем

PHP код:

void DevelopersComment(Editor e)
{
    int startLine = e.selectionStartLine();
    int endLine   = e.selectionEndLine();
    int startCol;
    str startStr;

    // >> GEV() 25 Авг 2009 GEV_NewProjectWithComment Создание новых проектов
    boolean         header = startLine == 1 && endLine == 1 && e.selectionStartCol() == e.selectionEndCol();
    ;
     if (header)
     {
        DEV_Scripts::commentCreateMethod(e);
     }
     else
     {
        DEV_Scripts::commentChangeMethod(e);
     }

} 


Исправляем getApplicableScripts и добавляем то что стоит между тегами

PHP код:

 // >> GEV() 29 Сен 2009
 ...
    // << GEV() 29 Сен 2009 


В итоге должно получиться что то вроде такого кода.

PHP код:

// Use this method to control what scripts are shown on the scripts popup menu in the editor
container getApplicableScripts(Editor e)
{
    classId id = classnum(EditorScripts);
    TreeNode AOTNode = EditorScripts::getVersionControllableNode(e);
    DictClass dc = new DictClass(id);
    int i;
    container scripts;
    str methodName;

    boolean applicableMethod (int offset)
    {
        DictMethod mi = dc.objectMethodObject(offset);
        if (mi.noParms() != 2)
            return false;
        if (mi.name() == methodstr(EditorScripts, showScripts))
            return false;
        if ((mi.name() == methodstr(EditorScripts, versionControl_checkOut) ||
            mi.name() == methodstr(EditorScripts, versionControl_getLatest)) &&
            (!versioncontrol.parmSysVersionControlSystem() || !AOTNode ||
            versioncontrol.allowEdit(AOTNode)))
                return false;
        if ((mi.name() == methodstr(EditorScripts, versionControl_undoCheckOut) ||
            mi.name() == methodstr(EditorScripts, versionControl_checkIn)) &&
            (!versioncontrol.parmSysVersionControlSystem() || !AOTNode ||
            !versioncontrol.allowEdit(AOTNode)))
                return false;
        if (mi.parameterType(1) == Types::Class)
            return mi.returnType() == Types::void;
        return false;
    }

    // >> GEV() 29 Сен 2009
    ;

    // > AxAssist, 10.10.2007
      if(DEV_AxAssistSingleton::getThisClass().parmAltMEmulate())
    {
        DEV_AxAssistSingleton::getThisClass().parmEditor(e);
        DEV_AxAssistSingleton::getThisClass().parmAltMEmulate(false);
        return connull();
    }
    // < AxAssist, 10.10.2007
    // << GEV() 29 Сен 2009

    // Insert menu items.
    for (i = 1; i <= dc.objectMethodCnt(); i++)
    {
        if (applicableMethod (i))
        {
            methodName = dc.objectMethodObject(i).name();
            scripts += methodName;
        }
    }

    return scripts;
} 


Ну а дальше читаем инструкцию и пользуемся). Будут проблемы пишите постараюсь помочь.

[kashperuk]

Хмм. Интересно. Мастер создания проектов уж очень похож на мой

[KingPeas]

Цитата:

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

Хмм. Интересно. Мастер создания проектов уж очень похож на мой

А это он и есть. Немного допилил чтобы не изобретать велосипед. На авторство не претендую).
По сути весь Плагин построен на использовании Мастера проектов, AxPath и доступ к Editor через инструментарий AxAssist. Больше ничего нового не выдумывал, воспользовался тем что было.

[kashperuk]

А - тогда прикольно. Как говориться, приятно свой код видеть "используемым"

[KingPeas]

Что-то сам перечитал темку и понял что ничего толком то и не объяснил про плагин.
Основная задача фиксировать изменения которые делались в AOT.

Немного истории.
Мы (то бишь программисты) в отделе вели учет что сделано и фиксировали основные задачи выполненные по запросам от пользователей (своих и наших клиентов) в файле Excel. Дело неблагодарное, заводить всю эту информацию руками. Наш архитектор предложил перенести все это дело в систему и заодно фиксировать все выполняемые в рамках проекта изменения. В качестве отправной точки взял Мастер проектов от kashperuk(за что Ивану отдельное спасибо) и при создании проектов добавил журнал проектов чтобы хранить информацию по запросам в рамках проекта. Ну а дальше используя приемы Tabax и AxAsist добавил функции чтобы фиксировать три события: Создание, Изменение и Удаление в AOT.

Все изменения фиксируются в рамках текущего проекта. Журнал ведется непосредственно в Axapta. Изменения фиксируются при помощи кнопок вынесеных на панель Tabax. Просто выделяем в AOT измененные узлы и жмем кнопку которая фиксирует в журнал характер изменения.В журнал сохраняется характер изменений и адрес (AxPath) к изменяемому узлу, что позволяет легко перейти к объекту прямо из журнала.

При внесении изменений в код методов используется общий шаблон комментария с указанием номера проекта, даты изменения, автора и небольшого описания.
Например:

public void init()
{
    ;
    common = element.args().record();


    super();

    element.initXRouteTemplateId();//den sibant_249
    //  >> EGurl(SIBANT) 29 Июл 2011 Shared:GEV_553_Cont (Акты выполненных работ для поставщиков)
    this.initStrList();
    //  << EGurl(SIBANT) 29 Июл 2011 Shared:GEV_553_Cont (Акты выполненных работ для поставщиков)

}

Естественно все это фиксируется в журнале и всегда можно перейти к коду прямо из журнала. Чтобы не плодить строки изменения фиксируются по одному элементу AOT для одного типа изменения не больше одного раза в сутки. То есть если в один метод вносим 10 изменений в программный код в разные места то в журнале будет одна запись, но найти все изменения не составит труда, поскольку весь код отмечен однообразными комментариями.Также можно скажем выделить десяток полей таблицы которые были модифицированы и хоть тысячу раз нажимать кнопку "Изменен". В журнале будет одна запись по каждому объекту.

В последующем добавил еще один журнал маркеров. По сути то же самое, но позволяет сохранить для себя некие закладки по которым можно найти узловые элементы анализа при работе с системой. Например разбираемся с неким модулем и копаемся среди классов. Бывает так зароешься в код, что количество страниц потеряется. Вспоминаешь что где то тут был нужный метод и уже не так просто его найти. А так пометил маркером и через журнал легко всегда его найдешь)

Ведение учета не требует больших усилий. А главный плюс который чувствуется со временем, так это возможность всегда вернутся к проекту и не вспоминать мучительно что же ты здесь делал. Опять же если проект сделан кем то другим, намного проще разбираться что было сделано.
А еще он нам очень пригодился когда проводился Аудит на предприятии нашей ИС. Мы с легкостью предоставили аудиторам полную информацию по тем проектам которые выполнялись в рамках сопровождения по запросам пользователей: от описания по проекту, до перечня изменений выполненных в системе для обработки запроса.

Пример: Поступает запрос ну скажем восстановить форму которая была откорректирована месяц назад программистом который уже уволился. Уже не надо искать старый запрос, находить какой проект для него был создан, искать в проекте что и когда изменялось по запросу. Открываем журнал изменений, через поиск находим требуемый проект и смотрим список того что делалось.

[belugin]

А вообще для этих целей есть контроль версий. Я даже свой писал для трёшки а в 2009 есть из коробки. Плюс в том, что можно использовать кучу стандартных инструментов, например кто и зачем изменил вот эту строчку кода

[KingPeas]

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

[S.Kuskov]

Цитата:

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

Все изменения фиксируются в рамках текущего проекта. Журнал ведется непосредственно в Axapta.

А разработка ведётся в реальном приложении или в отдельном? Если в отдельном, то каким образом вы переносите свои изменения, проектами, слоем? А журнал изменений переносите в реальную базу?

[KingPeas]

Разрабатываем в разработке. Тестируем на тесте. Работаем на реальном. Все как положено. Изменения переносим проектами между приложениями. А журнал изменений у нас переносится периодически через группу определений. Просто выгружаем стандартным способом через экспорт/импорт данных.
В планах было сделать что нибудь чтобы автоматом выгружалось и грузилось все на рабочее, но пока это только планы...

[KingPeas]

Конечно сие не есть хорошо, но у меня в коде прописан Шаблон формирования комментария. Там указано наше предприятие, поэтому кому будет нужда правим под себя код класса DEV_Scripts, а именно методы commentChangeMethod и commentCreateMethod.
Помимо всего прочего в документации не описано что в формах Настройки проектов и Реестр изменений двойной щелчок по полю Проект приводит к открытию проекта в отдельном окне. А в форме реестр изменений двойной щелчок по наименованию элемента открывает объект, а по коду открывает указанный метод.

[KingPeas]

Прошу помощи чтобы исправить небольшой баг. Сегодня с утра получил письмо в личку, товарищ жалуется что у него после регистрации комментариев в редакторе кода становится неактивным панель управления и он не может сохранить изменения. У меня наблюдается такая же штука, но я привык сохраняться по Ctrl+S поэтому сильно никогда и не мучился. Полез искать как с этим разобраться не смог найти как заставить окошко перерисоваться.