вторник, 30 ноября 2010 г.

1C начинается тут. Вывод на печать параметров документа, не сохраненного в БД.

Будем по-тихоньку изучать разработку конфигураций для 1С "Предприятие".
Для начала лишь пару слов, которых будет достаточно, чтобы вникнуть в суть языка программирования 1С: "всё - объекты". Любая часть конфигурации: справочники, документы - это все объекты. Оно и правильно, оно и удобно. Только проблема в том, что есть определенное ограничение на создаваемые объекты. Если в любом ООП языке любой объект - это определенный тип данных с определенными полями и методами, задаваемыми самим разработчиком, которые можно создавать динамически, на лету, то в 1С такое не прокатит. В 1С перечень возможных объектов ограничивается настройками Конфигурации, т.е. если описан объект "Справочники.Тест", у которого есть поле "Параметр", то в коде нельзя будет изменить этот объект, создав у него, например, новое поле:
Объект = Новый Справочники.Тест;
Объект.Параметр = 1; // предположительно, что значение - целое число
Объект.НовыйПараметр = 2; //компилятор выдаст ошибку, что это поле неизвестно

Я уж молчу про минимальное наследование. Хотя это и не обязано быть, ибо язык в 1С чисто условный, его сложно назвать полноценным языком программирования.

И вот конкретный пример. Есть документ в конфигурации Документ.ЗаменаКартриджа (документ о замене картриджа для принтера), соответственно, есть и объект Справочники.Картридж. Задача - воспользовавшись конструктором печати, вывести в Макет Код и Наименование картриджа.
Это именно отдельная задача, ибо по дефолту конструктор использует только заранее о
87;ределенные поля документа ЗаменаКартриджа, т.е. ЗаменяемыйКартридж, и, после привязки Макета к процедуре Печать(), сгенерированной конструктором, в поле Макета <ЗаменяемыйКартридж> вставляется наименование экземпляра объекта Справочники.Картридж. А как же вывести код картриджа?
А вот так:

Шапка = Макет.ПолучитьОбласть("Шапка");

Шапка.Параметры.Заполнить(ЭтотОбъект);

Шапка.Параметры.ЗаменяемыйКартриджНаименование =
ЭтотОбъект.ЗаменяемыйКартридж.Наименование;
Шапка.Параметры.ЗаменяемыйКартриджКод =
ЭтотОбъект.ЗаменяемыйКартридж.Код;

Т.е. я соответствующей ячейке Макета, желая выводить данные по картриджу в виде "Код (Наименование)", выбрал тип данных "Шаблон" (в нем можно группировать Параметры с Текстом) и прописал
[ЗаменяемыйКартриджКод] ([ЗаменяемыйКартриджНаименование])

Т.е. в [] я определил названия дополнительных параметров Макета.
Соответственно, осталось лишь руками изменить код процедуры Печать(), заполнив соответствующие поля Макета данными, полученным из формы Документа, которые в процедуру поступают в виде объекта документа ЭтотОбъект (аналог ООПшного this).

среда, 24 ноября 2010 г.

XLS vs ODS

Почему нужно пользоваться OOo вместо M$O? Очень просто: хотя бы потому, что формат xls имеет ограничение на количество столбиков табличного документа по номеру до IV, а OOo лишен этого ограничения. Поэтому лучше использовать формат ods, а не xls.

Debian Lenny i686 5.05 + Pentium Dual-Core part 2 (+переименование дисков)

Оказалось, что архитектура с x86_64 тоже не подошла. Хуже того, Debian с ней просто откзалась даже запускать инсталлятор. Последний шанс представляла архитектура i386. Зачем? Почем? Старая же архитектура! Выбора нет. Сказано - сделано. Система встала отлично, запустилась отлично. Был прогнан краш-тест с циклом ребутов и перезагрузок - система выдержала. Радость не знала границ! :)
Далее возникла проблема. Ибо сидюк у меня стоял SATA, а винт был IDE, то отключение привело к переименование девайсов винтов с sda на hda, что отражалось при загрузке как
WARNING bootdevices may be renamed

Решилось все достаточно просто. BusyBox, загрузившийся в виду невозможности старта основной системы, имеет на борту vi (я уже люблю его :) ), но файловая система рабочей машнки не смонтирована, поэтому находим девайс раздела (у меня это был hda1) и монтируем куда-нибудь:
mkdir /tmp/hda1
mount -t ext3 /dev/hda1 /tmp/hda1

Далее надо поправить grub:
vi /tmp/hda1/boot/grub/menu.lst

И поправить там в конфиге меню загрузки в строках
kernel /boot/vmlinuz-x.x.xx-x-x root=/dev/sda1 ro noquiet

на, в моем случае, hda1.
Далее надо поправить /etc/fstab, там, думаю, уже и без меня понятно, что и на что править.
Ну и священный "reboot".

четверг, 18 ноября 2010 г.

Debian Lenny i686 5.05 + Pentium Dual-Core

Пробовал ставить данную систему на комп с данным процессором. Система поставилась отлично, без нареканий, но вот дальше начались проблемы с загрузкой ядра, а именно: оно не хотело грузиться.
Проблема состояла в следующем: Pentium Dual-Core создан на архитектуре amd64(x86_64), а у меня сборка была с ядром 2.6.26-686. Как раз таки поддержка ядром архитектуры i686 (она же ia64 - жуткое наследние "полудохлой Intel Itanium" (с))не давала нормально ему работать. Amd64 - сие называется так, ибо AMD впервые разработала эту архитектуру.
Нелогичность заключается не в названии даже, а в том, что сия Debian распрекрасно ставится и работает на процессоре Celeron Dual-Core, а на Pentium Dual-Core уже не хочет, хотя ядро и там, и там Wolfsdale. Не разбирался с данным фактом, но, видимо, у Intel по этому поводу свои "заморочки".
Итог: придется ставить на Pentium Dual-Core архитектуру x68_64.