Gustav: Unsorted, или Записки DAX-дилетанта - II

[Gustav]

История берет свое начало здесь: Создание нескольких экземпляров Excel. Там же указаны некоторые практические шаги по задачам, упоминаемым здесь.

Итак, в очередной раз столкнулся с этой "миной": разработчики (из весьма уважаемой компании, вроде пора бы уж... ан, увы!) использовали файл с расширением XLS (т.е. обычный файл Excel) в качестве шаблона для одного из наших отчетов. По закону подлости "заряд" сработал в напряженную пору конца года, когда этот отчет понадобился многим пользователям и повалились ошибки из-за монопольного захвата шаблонного файла.

Не препарируя код Аксапты, администратор настроил в Excel общий доступ для файла. Захваты прекратились, но появилось ненужное стандартное диалоговое окно с запросом имени сохраняемого файла. При этом по умолчанию имя предлагается с "единичкой" на конце: <ИсходноеИмяФайла>1.xls - т.е. как и в случае создания нового файла от шаблона XLT, за одним исключением - при порождении от XLT не требуется сиюминутного ввода имени нового файла.

Интересно, что сохранять файл в ответ на ненужное окно совсем не обязательно, т.е. можно нажать Cancel - при этом в памяти остается несохраненный файл с именем по умолчанию. Не знаю, считать эту "фичу" Excel "багой" или нет, но, по крайней мере, знать о такой особенности поведения надо. Пользователя же это лишнее ненужное окно, разумеется, раздражает вне зависимости от степени его осведомленности в этих тонкостях. Для наглядной демонстрации того, о чем идет речь, можно выполнить в окне отладки Excel такую команду: Application.Workbooks.Add("<полное имя файла, которому дан общий доступ>.XLS") и всё увидеть своими глазами.


Напрашивающиеся возможные сценарии использования "шаблона" XLS в подобных ситуациях выглядят следующим образом:

1. Невидимое для пользователя открытие шаблонного XLS-файла (командой Workbooks.Open(<имя файла>.xls)), программное копирование из него шаблонного листа в новый файл, закрытие шаблонного XLS-файла, дальнейшая работа с новым файлом. Несмотря на быстрые автоматические операции, все равно возможны конфликты пользователей в борьбе за файл (без общего доступа).

2. Открытие XLS-файла без общего доступа как шаблона (командой Workbooks.Add(<имя файла>.xls)), сохранение под новым именем. В промежутке между открытием и сохранением другие пользователи не могут воспользоваться файлом. Практика показала, что конфликты успевают возникнуть даже при быстром программном сохранении файла под именем, ранее запрошенным у пользователя (как дополнительное неудобство такого программного варианта - обязательность сохранения файла на диске).

3. Открытие XLS-файла с общим доступом как шаблона (командой Workbooks.Add(<имя файла>.xls)), борьба с ненужным окном, сохранение под новым именем. Тем не менее, постоянный свободный доступ других пользователей к файлу.


Эти три сценария приведены для того, чтобы обрисовать примерный алгоритм борьбы с проблемами, возникающими из-за использования файла XLS в качестве шаблона:

* Если вы настроили общий доступ к файлу и проблемы прекратились (пользователи не конфликтуют и лишнее окно не появляется), то, скорее всего, используется сценарий 1 и ваши проблемы на этом закончились (в код лезть не придется).

* Если же после настройки общего доступа появилось лишнее окно, то вы, вероятно, перешли от сценария 2 к сценарию 3. Вам следует при помощи Excel переделать файл XLS в XLT (не просто изменив одну букву в расширении, а сохранить файл как шаблон) и внести необходимые изменения в код X++ (здесь уже просто заменив одно расширение файла на другое).

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


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

Ну, или работать в своей Аксапте одному в одной сессии - тоже способ избежать блокировок со стороны других пользователей. С Наступающим!

[Gustav]

Столкнулся со следующими проблемами при создании наследника RunBaseBatch дублированием (копированием) из другого класса-наследника (работаю с Ax 3.0 SP4):

1) невозможность отобразить вкладку "Пакет" - бездействие метода canGoBatch;
2) невозможность откомпилировать новый класс - ошибка в методе main с сообщением "Нельзя создать объект, поскольку абстрактный метод RunBase.pack() не реализован."

По первой проблеме нашёл рекомендацию здесь: Замена стандартной формы Dialog. Не выводится вкладка Пакет. . Действительно, заработало после того, как создал класс не просто дублированием другого класса, а создал новый класс вручную и перетащил по очереди методы мышкой из исходного класса.

Вторая ситуация описана в теме: Ошибка в "Тренинге по Средствам Разработки" , но явный метод борьбы не указан. Поэтому изложу свой.

Как и из-за чего именно возникает проблема 2 по ходу дублирования (копирования) не заметил, но научился вопроизводить так:

* Контекстной командой Дублировать создадим копию класса Tutorial_RunBaseBatch - CopyOfTutorial_RunBaseBatch.
* Изменим метод main, подогнав его под новый класс:

static void main(Args args)
{
    CopyOfTutorial_RunbaseBatch    tutorial_RunBase;
;
    tutorial_RunBase = new CopyOfTutorial_RunbaseBatch();

    if (tutorial_RunBase.prompt())
        tutorial_RunBase.run();
}

Всё хорошо, всё компилируется и выполняется.

* Переименуем метод pack, например, в mypack. Компиляция теперь проходит неудачно и указывает на метод main c выдачей упомянутого выше сообщения.
* Возвращаем методу pack его прежнее имя pack. Компиляция в ответ не становится удачной и информирует о той же ошибке.

И вот то, что помогло: комментируем в main строку c new, компиляция - ОК, далее раскомментируем строку и опять компилируем - ОК.

А самый первый раз наугад поборолся с проблемой 2 так: удалил метод main, скомпилировал класс без него и создал метод заново вручную.