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

Ядро имеет большое количество программирования, и я полагаю, что программисты должны читать по крайней мере некоторые его исходные файлы и понимать их. Сказав это, я также верю в значение игры с системой сначала и выяснением вопросов позже. Когда я узнаю новый язык программирования, я не начинаю с чтения библиотечного кода, а пишу маленькую программу "hello, world". Я не вижу, почему начинающий разбираться с ядром должен быть действовать иначе."

Книга `Настройка производительности UNIX-систем` отвечает на два важнейших вопроса: как добиться максимального эффекта без покупки дополнительного оборудования, и в каких случаях его все же стоит приобрести (больше памяти, более быстрые диски, процессоры и сетевые интерфейсы). Вложение денежных средств - не панацея. Адекватно оценить необходимость обновления и добиться максимальной производительности можно, только хорошо представляя работу компьютеров и сетей и понимая распределение нагрузки на системные ресурсы. Авторы книги оказали неоценимую помощь администраторам, подробно и аргументировано рассказав обо всех тонкостях искусства настройки систем. Полностью обновленное издание ориентировано на Solaris и Linux, но обсуждаемые принципы применимы к любым системам. В книге рассматриваются настройка параметров, управление рабочим процессом, методы измерения производительности, выявление перегруженных и неработоспособных участков сети, добавлен новый материал о дисковых массивах, микропроцессорах и оптимизации программного кода.

Основным понятием CSS является стиль – т. е. набор правил оформления и форматирования, который может быть применен к различным элементам страницы. В стандартном HTML для присвоения какому-либо элементу определенных свойств (таких, как цвет, размер, положение на странице и т. п.) приходилось каждый раз описывать эти свойства, даже если на одной страничке должны располагаться 10 или 110 таких элементов, ничуть не отличающихся один от другого. Вы должны были десять или сто десять раз вставить один и тот же кусок HTML-кода в страничку, увеличивая размер файла и время загрузки на компьютер просматривающего ее пользователя.

CSS действует другим, более удобным и экономичным способом. Для присвоения какому-либо элементу определенных характеристик вы должны один раз описать этот элемент и определить это описание как стиль, а в дальнейшем просто указывать, что элемент, который вы хотите оформить соответствующим образом, должен принять свойства стиля, описанного вами. Удобно, не правда ли?

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

Кроме того, CSS позволяет работать со шрифтовым оформлением страниц на гораздо более высоком уровне, чем стандартный HTML, избегая излишнего утяжеления страниц графикой.

Давайте рассмотрим, как мы можем воплотить столь замечательные возможности в жизнь.

Мы предполагаем, что вы на базовом уровне знакомы с HTML, Java и web-серверами и у вас имеется доступ к компьютеру, на котором можно установить небольшой web-сервер, стандартный компилятор Java и другие служебные программы. Редактировать данные XML можно с помощью любого текстового редактора, либо вы можете использовать один из многочисленных коммерческих или находящихся в свободном доступе специализированных редакторов XML. Если эти требования выполнены, то практически любой человек, который работает с данными в той или иной форме, потенциально является пользователем XML. Трудно представить себе такую область человеческой деятельности, для которой в Интернете не нашлось бы ни одного относящегося к ней проекта, использующего язык XML.
В нашей книге мы будем использовать сервлеты [Так, по-видимому, по аналогии с апплетами авторы называют программы, написанные на языке Java и выполняющиеся на сервере — Примеч ред. ] Java и JSP-страницы (JavaServer Pages) для создания web-приложений, работающих с данными XML. Сервлеты выполняются на web-сервере, осуществляя те функции, которые ранее возлагались на сценарии CGI. JSP-страницы позволяют объединять элементы разметки HTML и фрагменты кода Java. Технология сервлетов и JSP-страниц развивается примерно так же быстро, как язык XML.

В удобной, наглядной форме описаны все элементы PHP - популярного языка CGI-сценариев. Рассмотрены не только особенности синтаксиса языка, но и редактирование кода в программах EditPlus и UltraEdit, а также установка PHP и сервера Apache. Материал систематизирован таким образм, что читатель может использовать книгу и как учебник и как справочник. Примеры, взятые из реальной практики Web-программирования позволяют лучше усвоить теоретический материал. Книга расчитана на самую широкую аудиторию - не только на новичков, но и на опытных программистов.

Эта книга уникальна. Она написана специально для Вас, если Вы чувствуете необходимость реализовать на создаваемых Вами Web-страницах собственные сценарии. Пусть у Вас мало свободного времени, а детальное изучение используемых для этого языков не представляется Вам лучшим способом включиться в работу. Хорошо, если Вы уже имеете некоторый опыт создания Web-страниц, знакомы с HTML и можете разобраться в HTML-кодах. В этом случае книга, которую Вы держите в руках - это именно то, что Вам необходимо.
Издание состоит из 12 глав. В каждой главе раскрываются наиболее важные особенности написания кодов и возможности обогащения HTML с использованием JavaScript. В тексте приводятся листинги программ. В целях приобретения опыта написания программ мы рекомендуем вводить примеры с клавиатуры, запоминать их в отдельном файле, который затем может быть загружен в броузер и проверен на работоспособность. Книга является практическим руководством, рассчитанным на начинающих пользоваться возможностями JavaScript для обогащения своих страниц.

У всех, кто когда-либо начинал более или менее серьёзно заниматься созданием вебстраниц, обязательно возникала мысль - а как неплохо бы было, если бы повторяющиеся фрагменты HTML-кода можно было бы писать только по одному разу - чтобы затем они вставлялись бы в нужные места страниц автоматически. Самые продвинутые пытались воспользоваться Java-скриптами, чтобы добиться этого - но тогда страницы начинали растекаться жиром на десятки килобайт, а браузеры посетителей захлёбывались в сложном и обьёмном коде скриптов.

Между тем решение проблемы давно уже было - правда клиентам бесплатных хостингов оно не было доступно. На Webservis.ru оно есть и зовут его "SSI" - "Server Side Includes". Перевести это можно, в принципе, как «сборкой страниц занимается вебсервер».

Издание посвящено вопросам программирования на языке ассемблера для процессоров Intel Pentium. Рассмотрен широкий круг вопросов, начиная с основ программирования на ассемблере и заканчивая применением самых современных технологий обработки данных, таких как MMS, SSE и SSE2. Материал книги раскрывает методику оптимизации программного кода для всех поколений процессоров Intel Pentium, включая Intel Pentium 4. Теоретический материал подкреплен многочисленными примерами программного кода. Для широкого круга читателей, от студентов до опытных разработчиков программного обеспечения.

Чаще всего изображения со случайным кодом (так называемая captcha) используются для защиты от флуда (автоматизированного ввода сообщений), некоторые сервисы находят им применнение в качестве раздражителя (для перехода на платный вариант).

В общем, может пригодиться. PHP код следующий:

PHP - Код

$width = 100;                //Ширина изображения
$height = 60;                //Высота изображения
$font_size = 16;               //Размер шрифта
$let_amount = 4;            //Количество символов, которые нужно набрать
$fon_let_amount = 30;        //Количество символов на фоне
$font = "fonts/cour.ttf";    //Путь к шрифту
 
//набор символов
$letters = array("a","b","c","d","e","f","g");        
//цвета
$colors = array("90","110","130","150","170","190","210");    
 
$src = imagecreatetruecolor($width,$height);    //создаем изображение                
$fon = imagecolorallocate($src,255,255,255);    //создаем фон
imagefill($src,0,0,$fon);                        //заливаем изображение фоном
 
for($i=0;$i < $fon_let_amount;$i++)            //добавляем на фон буковки
{
    //случайный цвет
       $color = imagecolorallocatealpha($src,rand(0,255),rand(0,255),rand(0,255),100);    
       //случайный символ
       $letter = $letters[rand(0,sizeof($letters)-1)];    
    //случайный размер                                
       $size = rand($font_size-2,$font_size+2);                                            
       imagettftext($src,$size,rand(0,45),
           rand($width*0.1,$width-$width*0.1),
        rand($height*0.2,$height),$color,$font,$letter);
}
 
for($i=0;$i < $let_amount;$i++)        //то же самое для основных букв
{
   $color = imagecolorallocatealpha($src,$colors[rand(0,sizeof($colors)-1)],
           $colors[rand(0,sizeof($colors)-1)],
           $colors[rand(0,sizeof($colors)-1)],rand(20,40)); 
   $letter = $letters[rand(0,sizeof($letters)-1)];
   $size = rand($font_size*2-2,$font_size*2+2);
   $x = ($i+1)*$font_size + rand(1,5);        //даем каждому символу случайное смещение
   $y = (($height*2)/3) + rand(0,5);                            
   $cod[] = $letter;                           //запоминаем код
   imagettftext($src,$size,rand(0,15),$x,$y,$color,$font,$letter);
}
 
$cod = implode("",$cod);                    //переводим код в строку
 
header ("Content-type: image/gif");         //выводим готовую картинку
imagegif($src);

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

Через HTML такое изображение вызывается стандартно:

Код

<img src="sec_pic.php" alt="защитный код">

Скачать скрипт генерации защитного кода с полным набором символов и возможностью подключения своих шрифтов можно здесь [url=/uploads/files/public/secpic.rar]secpic.zip[/url]

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

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

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

Если Вы туда "полезете", то "с ума сойдете", а микроконтроллер, по своей сути, есть тот же самый компьютер, но только простой. Программисту только нужно детально знать, каким именно образом "приказать железяке" сделать то, что необходимо для достижения задуманного. Микроконтроллер можно представить себе как некий универсальный "набор" многофункциональных модулей (блоков), "рычаги управления" которыми находятся в руках программиста. Этих "рычагов" достаточно большое количество, и естественно, их нужно освоить и точно знать, что именно произойдет, если "дернуть" (дать команду на языке ассемблер) за тот или иной "рычаг". Вот здесь-то уже нужно знать, как "отче наше", каждую деталь и не жалеть на это "узнавание" времени. Только таким образом пустую "болванку" (незапрограммированый ПИК) можно "заставить"
выполнять какие-то "осмысленные" действия, результат большей части которых можно проверить в симуляторе MPLAB (об этом - позднее), даже не записывая программу в ПИК.

Итак, необходим переход к "модульному" мышлению. Любой микроконтроллер можно уподобить детскому конструктору, в состав которого входит множество всяких предметов, манипулируя с которыми, можно получить тот или иной конечный "продукт". Давайте с ними разберемся и "разложим все по полочкам". В качестве примера я буду использовать один из самых распространенных PIC контроллеров PIC16F84A. Он является как бы "проматерью" более сложных ПИКов, содержит минимальный "набор" модулей и как нельзя лучше подходит для первичного "въезда в м/контроллеры".



Начнем с энергонезависимой памяти (память программ и память данных).
Информация, заложенная в энергонезависимую память, сохраняется при выключении питания, и поэтому именно в нее записывается программа.
То "место" энергонезависимой памяти, куда записывается программа, называется памятью программ. Объем памяти программ может быть различен. Для PIC16F84A, он составляет 1024 слова. Это означает, что он предназначен для работы с программами, объем которых не превышает 111024 слов.

Слово памяти программ не равно одному байту (8 бит), а больше его (14 бит). Отдельная команда, которую ПИК будет в дальнейшем выполнять, занимает одно слово в памяти программ. В зависимости от названия этой команды в ассемблере, слово принимает то или иное числовое значение в машинном коде. После записи в ПИК "прошивки" программы, слова памяти программ (машинные коды) как бы "превращаются" в команды, которые располагаются, в памяти программ, в том же порядке, в котором они следуют в исходном тексте программы, написанном на языке ассемблер, и в том же порядке им присваиваются адреса, при обращении к которым, та или иная команда "извлекается" из памяти программ для ее выполнения. Последовательность же их выполнения определяется логикой программы. Это означает то, что выполнение команд может происходить не в порядке последовательного возрастания их адресов, с шагом в одну позицию (так называемый инкремент), а "скачком". Дело в том, что только уж самые простейшие программы, в пределах одного их полного цикла, обходятся без этих "скачков", называемых переходами, и выполняются строго последовательно. В остальных же случаях, так называемая (мной) "рабочая точка программы" "мечется по тексту программы как угорелая" (как раз благодаря этим самым переходам).

Термин "рабочая точка программы" - моя "самодеятельность". В свое время, я был очень сильно удивлен отсутствием чего-то подобного в информации, связанной с объяснением работы программ. Казалось бы, чего проще, по аналогии, например, с рабочей точкой транзистора, сделать более комфортным "въезд в механику" работы программ? Так нет же, как будто специально, придумываются такие "головокружительные заменители", причем, в различных случаях, разные, что запутаться в этом очень просто. Итак, рабочую точку программы можно представить себе в виде некоего "шарика от пинг-понга", который "скачет" по командам текста программы в соответствии с алгоритмом (логикой) исполнения программы. На какую команду "шарик скакнул", та команда и исполняется. После этого он "перескакивает" на другую команду, она исполняется, и т.д. Эти "скачки" происходят непрерывно и в течение всего времени включения питания устройства (исполнения программы).
Любая более-менее сложная программа разбивается на части, которые выполняют отдельные функции (своего рода программки в программе) и которые называются подпрограммами. Атрибут любой подпрограммы - функциональная законченность производимых в ней действий.
По сути своей, эта "выдумка" введена в программирование для удобства реализации принципа "разделяй и властвуй": "врага" ведь гораздо легче "разгромить по частям, чем в общей массе". Да и порядка больше.

Безусловные переходы (переходы без условия) между подпрограммами (если они последовательно не переходят одна в другую), осуществляются при помощи команд безусловных переходов, в которых обязательно указывается адрес команды в памяти программ (косвенно - в виде названия подпрограммы или метки), на которую нужно перейти. Существуют также переходы с условием (условные переходы), то есть, с задействованием так называемого стека. Более подробно о переходах я расскажу позднее. Адреса команд определяются счетчиком команд (он называется PC). То есть, каждому состоянию счетчика команд соответствует одна из команд программы. Если команда простая, то счетчик просто инкрементируется (последовательно выполняется следующая команда), а если команда сложная (например, команда перехода или возврата), то счетчик команд изменяет свое состояние "скачком", активируя соответствующую команду.

Примечание: инкремент - увеличение на единицу величины числа, с которым производится эта операция, а декремент - уменьшение на единицу (так называемые комплиментарные операции). В простейшем случае, то есть в случае отсутствия в программе переходов, счетчик команд PC, начиная с команды "старта" (нулевой адрес), многократно инкрементируется, 12 последовательно активизируя все команды в памяти программ. Это означает, что в большинстве случаев, за каждый так называемый машинный цикл (такт работы программы: для ПИКов он равен четырем периодам тактового генератора) работы ПИКа, происходит исполнение одной команды. Есть и команды исполнение которых происходит за 2 машинных цикла (м.ц.), но их меньше. Команд, которые исполняются за 3 м.ц. и более нет. Таким вот образом, на большинстве участков программы (я их называю "линейными участками"), последовательно и перебираются адреса в памяти программ (команды последовательно исполняются).

В более сложных программах, с большим количеством условных и безусловных переходов, работу счетчика команд PC можно охарактеризовать фразой "Фигаро здесь, Фигаро там". 1 машинный цикл (м.ц.) равен 4-м периодам тактового генератора ПИКа. Следовательно, при использовании кварца на 4 Мгц., 1 м.ц.=1 мкс. Выполнение программы, в рабочем режиме (кроме работы в режиме пониженного энергопотребления SLEEP), никогда не останавливается, то есть, за каждый машинный цикл (или за 2, если команда исполняется за 2 м.ц.) должно выполняться какое-либо действие (команда). Тактовый генератор, формирующий машинные циклы, работает постоянно. Если его работу прервать, то исполнение программы прекратится.

Может сложиться ложное представление о том, что работу программы можно на какое-то время остановить, используя одну или несколько команд – "пустышек", не производящих полезных действий (есть такая команда NOP). Это представление не верно, так как в этом случае, речь идет только о задержке выполнения следующих команд, а не об остановке исполнения программы. Программа исполняется и в этом случае, так как "пустышка" есть та же самая команда программы, только не производящая никаких действий (короткая задержка). Если же нужно задержать выполнение каких-либо последующих команд на относительно длительное время, то применяются специальные, циклические подпрограммы задержек, о которых я расскажу позднее. Даже тогда, когда программа "зависает" ("глюк"), она исполняется, просто только не так, как нужно. Остановить (в буквальном смысле этого слова) исполнение программы можно только прекратив работу тактового генератора. Это происходит при переходе в режим пониженного энергопотребления (SLEEP), который используется в работе достаточно специфических устройств. Например, пультов дистанционного управления (и т.д.).

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

Общие выводы:
1. Команды программы "лежат" в памяти программ в порядке расположения команд в тексте программы.
2. Адреса этих команд находятся в счетчике команд PC и каждому адресу соответствует одна из команд программы.
3. Команда активируется (исполняется), если в счетчике команд находится ее адрес.
4. Активация команд происходит либо последовательно (на "линейном" участке программы), либо с переходом ("скачком") на другую команду (при выполнении команд переходов), с которой может начинаться как подпрограмма (переход на исполнение подпрограммы), так и группа команд, выделенная меткой (переход на исполнение группы команд, которой не присвоен "статус" подпрограммы).
5. Выполнение команд программы никогда не останавливается (за исключением режима SLEEP), и поэтому программа должна быть циклической.

Кроме памяти программ, PIC16F84A имеет энергонезависимую память данных (EEPROM память данных). Она предназначена для сохранения данных, имеющих место быть на момент выключения питания устройства, в целях их использования в дальнейшем (после следующего включения питания). Так же, как и память программ, память данных состоит из ячеек, в которых "лежат" слова. Слово памяти данных равно одному байту (8 бит). В PIC16F84A, объем памяти данных составляет 64 байта. Байты, хранящиеся в памяти данных, предназначены для их считывания в стандартные 8-битные регистры, речь о которых пойдет далее. Данные из этих регистров могут быть записаны в EEPROM память данных, то есть, может быть организован обмен данными между памятью данных и регистрами. Например, именно EEPROM память данных я использовал в своем частотомере для сохранения последних, перед выключением питания, настроек. Она же используется и для установки значений промежуточной частоты. Во многих программах, память данных вообще не используется, но это "вещь" исключительно полезная, и далее я расскажу о ней подробнее.

Известно, что на кнопки в экранных формах V7 можно «вешать» горячие клавиши. Однако количество оных оставляет желать лучшего – это только Fx с различными модификаторами (alt, ctrl, shift), при чём наиболее привлекательные сочетания (например, F1) уже зарезервированы системой. Но всё-таки существует способ привязать к кнопкам и иные сочетания клавиш – о нем я и расскажу. Однако этот способ не относится к стандартным и документированным, поскольку требует непосредственной (минуя конфигуратор) модифиикации форм.



Нам потребуется: файловый менеджер FAR, plug-in к нему по имени DocFileBrowser, справочник по кодам клавиш (в смысле, которые Virtual Keys, VK_), и любой HEX-редактор (можно использовать соответствующую функцию FAR'a).



Допустим, у нас есть некий внешний отчёт, на какую-то из кнопок которого мы хотим повесить "хоткей", отличный от стандартного. Открываем в FAR'e этот отчет через DocFileBrowser и видим, что он в себе набор stream'ов (которые можно запросто называть файлами, суть одна и та же):

Container.Contents
Container.Profile
Dialog Stream
Inplace description
Main MetaData Stream
MD Programm text

Какой файл к чему относится – я описывать не буду, про это и так неоднократно уже говорилось, тем более, что имена файлов более чем прозрачны. Да вы и сами все знаете ;-).

Так вот, нам нужен Dialog Stream. Распакуйте его куда-нибудь (простая операция Copy в FAR'e).

Теперь посмотрим, что он из себя представляет – это почти что обычный текстовый файл, за исключением первых трёх байт – там может быть все, что угодно (на самом деле, там длина файла).

Файл состоит из строчек типа:

Код

{"Закрыть","BUTTON","1342177291","70","142","54",
"14","0","0","4152","",
"#Закрыть","","-1","U","0","0","0","0","0","","",
"","0","-11","0","0","0","0","0","0","0","0","0",
"0","0","0","MS Sans Serif","-1","-1","0",
"Основной","{""0"",""0""}"},

На самом деле это всё одна строка, просто она разбита разбита для удобства чтения.

Так вот, последние {""0"",""0""} есть ни что иное, как модификатор (первое числовое поле) и Vkey_code назначенной кнопке горячей клавиши. Причём оба числа десятичные.

Модификатор означает:

0 – нет хоткея,
3 – есть;
+4 – Shift
+8 – Ctrl
+16 – Alt

например, для Alt+Shift+Key модификатор будет 23.

Теперь, зная VK_ нужной нам клавиши (например, 41H = 65 для "A"), мы можем вручную назначить, скажем, кнопке «Закрыть» хоткей Ctrl+A – для этого заменим ее «хвост» на такой: {""11"",""65""} и со спокойной совестью сохраняем наш файл.

Однако его длина изменилась – поэтому открываем файл каким-нибудь HEX-редактором, и правим: первый байт всегда FF, второй и третий – длина оставшегося куска файла (без учета этих трёх байт).

Как вычислить эту длину? Становимся на последний байт файла – допустим, это адрес 05ECH. Поскольку адресация идет с нуля, то всего в файле 05EDH байт. Вычитаем три (первых) – получаем 05EAH. Это число и ставим во второй и третий байты заголовка (естественно, младший байт идет первым – EA 05).

Далее – cохраняем, запаковываем Dialog Stream на место, закрываем файл (DocFileBrowser открывает файлы монопольно, 1С одновременно с ним тот же файл открыть не сможет).

Теперь открываем отчет в 1С, и наслаждаемся произведённым эффектом.

Напоследок хочу предупредить – редактирование свойств «пропатченной» кнопки в конфигураторе приводит к потере установленного хоткея, это вполне закономерно и ничего тут не поделать. Будьте внимательны.

К сему описанию прилагается демонстрационный пример с тремя хоткеями – Ctrl+D, Alt+D и просто D. При чем все они (D в том числе) действуют даже тогда, когда фокус находится в поле ввода.

Самое последнее: при вызове хоткея активный элемент не теряет фокуса!

В данной статье приведены общие сведения об организации работы системы 1С:Предприятие с распределенной информационной базой (ИБ). Также описаны внутренние особенности организации механизма работы с распределенными данными для того, чтобы специалисты, осуществляющие конфигурирование и администрирование распределенных систем могли лучшее понимать выполняемые системой действия. Данная информация может также быть использована для оценки дополнительных затрат ресурсов системы, расходуемых на поддержание распределенной информационной базы.

Так как средства системы 1С:Предприятие для работы с распределенными информационными базами поставляются отдельно, сначала кратко остановимся на назначении и основных принципах организации работы системы 1С:Предприятие с территориально удаленными подразделениями.



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

Для решения подобных задач предназначена компонента "Управление распределенными ИБ". С помощью указанной компоненты можно организовать двухуровневую структуру информационных баз (ИБ) системы 1С:Предприятие, состоящую из одной центральной и нескольких периферийных информационных баз, работающих с единой конфигурацией. При этом система будет стремиться поддерживать одинаковое состояние объектов данных во всех узлах распределенной ИБ.

Содержимое информационных баз синхронизируется путем переноса измененных объектов данных между каждой из периферийных и центральной ИБ. Для переноса данных используются так называемые файлы переноса данных. Перенос изменений выполняется только между центральной и периферийными ИБ. Перенос данных непосредственно между периферийными ИБ невозможен. Поэтому изменения данных, произведенные в одном из периферийных узлов распределенной ИБ попадают в другие периферийные узлы только через центральную ИБ.

В простейшем случае (по умолчанию) областью распространения изменений для всех объектов является вся распределенная ИБ. Таким образом, в случае если в течение какого-то времени изменения данных системы не будут производиться, и, в то же время, будут произведены все необходимые действия по обмену изменениями между узлами распределенной ИБ, то все узлы будут содержать абсолютно одинаковые данные.

В некоторых случаях может возникнуть необходимость в том, чтобы объекты того или иного типа никогда не попадали в те или иные узлы распределенной ИБ или никогда не покидали места своего создания. Для обеспечения такой возможности предназначен механизм настройки параметров миграции объектов. С его помощью можно ограничить распространение изменений объектов того или иного вида. Кроме того, в версии 7.7 системы 1С:Предприятие можно создавать периферийные ИБ, которые будут принимать информацию о измененных объектах из центральной ИБ, но не будут передавать изменения, сделанные в них самих.

Механизмы распространения изменений объектов работают полностью автоматически. Разработчик конфигурации лишен возможности вмешиваться в функционирование этих механизмов. Для того, чтобы механизмы распределенной ИБ начали работать, не нужно производить никаких специальных действий по конфигурированию системы.

Однако, для того, чтобы документы, элементы справочников и другие объекты, созданные в разных узлах распределенной ИБ, имели заведомо непересекающиеся пространства номеров, кодов и т. п., может потребоваться внести в конфигурацию некоторые изменения. Также изменения в конфигурации должны вноситься при необходимости обеспечить специальные ограничения работы пользователей на периферийных информационных базах.

Для переноса измененных объектов в распределенной ИБ и для первичного создания периферийной ИБ используется файл переноса данных. Он представляет собой упакованный (сжатый) файл, содержащий объекты информационной базы (все при создании периферийной ИБ или измененные при передаче изменений) в специальном формате. Формат данного файла не предназначен для использования его способами отличными от тех, которые предусмотрены механизмами выгрузки/загрузки и передачи изменений. Файл переноса фактически отражает содержимое объектов информационной базы в формате, не зависящем от формата базы данных. Это позволяет использовать в распределенной информационной системе в различных узлах различные форматы хранения данных, поддерживаемые системой 1С:Предприятие (DBF/CDX и MS SQL Server).



Перенос измененных данных производится "пообъектно". То есть единицей переноса данных является так называемый ведущий объект. С точки зрения работы в распределенной информационной базе в 1С:Предприятии существуют следующие типы ведущих объектов:

константа,

элемент справочника,

документ,

календарь,

счет бухгалтерского учета,

типовая операция.

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

Регистрация изменений объектов производится автоматически при любом изменении объекта, независимо от того каким способом это изменение производилось (интерактивно или из встроенного языка). Кроме того в версии 7.7 системы 1С:Предприятие для таких объектов как элементы справочников и документы появилась возможность управления регистрацией изменений. Для этого у соответствующих объектов метаданных введен признак "Автоматическая регистрация изменений". Если этот признак установлен (значение по умолчанию), то автоматическая регистрация производится, а если признак сброшен, то регистрация не производится и изменения объектов в распределенной ИБ не распространяются. Но и в данном случае, при выполнении записи изменений объектов из встроенного языка можно управлять регистрацией изменений с помощью метода встроенного языка РегистрацияИзменений().

Регистрация изменений ведущих объектов производится в специальной служебной таблице. При этом фиксируются следующие данные об изменении объекта:

Сам ведущий объект;

Идентификатор той ИБ, в которую должно быть передано изменение;

Идентификатор ИБ, в которую должно быть передано изменение, служит для отслеживания переноса данных в каждую из ИБ, с которой данная ИБ обменивается данными. Таким образом, при изменении какого-либо объекта в центральной ИБ в таблицу будет помещено по одной записи для каждой из зарегистрированных периферийных информационных баз. Если же изменение объекта происходит в периферийной ИБ, то в таблицу будет занесена только одна запись, соответствующая центральной ИБ, так как каждая из периферийных ИБ непосредственно взаимодействует только с центральной.

Заметим, что удаление объекта является частным случаем изменения. Оно также помечается в таблице регистрации изменений и передается при выгрузке.

Выгрузка и загрузка изменений

Каждая выгрузка изменений осуществляется в адрес конкретной ИБ. В файл переноса, создаваемый при выгрузке попадают все объекты, записи об изменениях которых содержатся в таблице регистрации изменений для данной ИБ.

Заметим, что выгружаются не изменения объектов, а сами измененные объекты. То есть, если в документе изменилось значение одного реквизита, то будет передаваться весь документ и он будет полностью перезаписан на той ИБ, в которую переносится. Как уже отмечалось, вместе с документом будут перенесены и сделанные им движения регистров, операция и проводки. Если изменяется любой реквизит справочника, то передается полностью весь элемент. При этом история периодических реквизитов передается целиком. Последнее означает, что изменения сделанные в истории периодического реквизита элемента на в двух ИБ не будут сливаться вместе.

В процессе выгрузки в таблице регистрации изменений отмечается выгрузка изменений объектов.

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

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

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

При загрузке изменений объектов из периферийной ИБ в центральную, в таблицу регистрации изменений (если, конечно, параметры миграции настроены соответствующим образом) заносятся записи, указывающие, что загруженные из периферийной ИБ изменения объектов должны быть переданы в другие периферийные ИБ.

Изменения конфигурации

Как уже отмечалось, при работе с распределенной ИБ, конфигурация системы может быть изменена только в центральном узле.

Для регистрации изменений конфигурации и передачи ее на периферийные ИБ используется тот же механизм, что и для объектов данных. При записи измененной конфигурации, в таблицу регистрации изменений объектов по числу известных периферийных ИБ заносятся записи, фиксирующие факт изменения конфигурации.

После записи измененной конфигурации в распределенной ИБ складывается такая ситуация, что центральная и периферийные ИБ работают фактически с разными конфигурациями. В таком состоянии созданные на периферийной ИБ файлы переноса данных не могут быть загружены на центральной ИБ по той причине, что в условиях различных конфигураций содержащаяся в файле информация не может быть правильно интерпретирована. Обмен будет восстановлен только после того, как в периферийную ИБ будет загружена измененная конфигурация с центральной ИБ. То есть после изменения конфигурации требуется выполнить перенос из центральной ИБ в каждую из периферийных, а уже затем выполнять перенос из периферийных ИБ в центр.

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

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

Для изменения уже работающей конфигурации можно рекомендовать использовать механизм загрузки измененной конфигурации. Он позволяет специалисту скопировать конфигурацию, выполнить в ней все необходимые изменения, отладить внесенные изменения (этот процесс может занять и несколько дней), а затем загрузить измененную конфигурацию в центральную ИБ, после чего изменения будут распространены на все периферийные ИБ с очередной передачей изменений. Такая последовательность позволит избежать многократной передачи измененной конфигурации в периферийные ИБ в процессе ее модернизации.

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

Продолжение статьи


[pagebreak]

Загрузка измененной конфигурации может завершиться неудачей, если измененная конфигурация не соответствует существующим данным. Например, было уменьшено число уровней справочника, а новое число уровней оказывается меньшим, чем фактически содержащееся в справочнике или в других подобных случаях. Если такое произошло, то следует привести данные в соответствие с новой конфигурацией или изменить конфигурацию в центральной ИБ и заново произвести выгрузку, чтобы ликвидировать возникшее противоречие.

Коллизии

При работе в реальных распределенных ИБ один и тот же объект может изменяться одновременно в различных узлах распределенной ИБ. И при переносе измененных объектов из одной ИБ в другую может случиться так, что в какую-либо ИБ будет загружаться объект, зарегистрированный в самой этой ИБ как измененный. Такая ситуация носит название коллизии. Приведем описание действий системы в наиболее типовых вариантах коллизий.

Один и тот же объект изменен более чем в одной ИБ.

Общий принцип здесь состоит в том, что "главным" считается изменение, произведенное в центральной ИБ. Отработка ситуации различается в зависимости от того, на какой ИБ - центральной или периферийной коллизия обнаружена. Если коллизия обнаружена на центральной ИБ, то есть при загрузке файла переноса из периферийной ИБ обнаружено, что один из измененных объектов также изменен и в центральной ИБ, то изменения объекта в центральную ИБ не загружаются. При этом гарантируется, что при очередной выгрузке в адрес периферийной ИБ будет передано состояние объекта как оно есть в центральной ИБ. Если же коллизия обнаружена на периферийной ИБ, то изменения объекта, прибывшие из центральной ИБ загружаются.

Объект, измененный в одной ИБ, удален в другой.

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

Аналогичные действия производятся, если коллизия обнаружена на периферийной ИБ.

Объект, удаленный в одной ИБ, не может быть удален в другой по причине наличия ссылок на него.

При загрузке изменений, если загружается информация об удалении объектов, автоматически включается механизм контроля ссылочной целостности и выполняется проверка наличия ссылок в данной ИБ на объекты, которые переданы как удаленные.

В случае обнаружения коллизии такого рода, вне зависимости от того на какой из ИБ она была обнаружена, выполняется следующее: удаление не выполняется, а в таблицу регистрации изменений заносится запись о том, что объект должен быть перенесен в адрес той ИБ, из которой была прислана информация о его удалении.

При очередном обмене объект восстанавливается в той ИБ, в которой он был удален, однако само содержание объекта будет соответствовать той ИБ, которая "отвергла" удаление.

Таким образом, управление распределенной информационной базой имеет определенную стратегию автоматического разрешения любых коллизий с описанными приоритетами. Однако, в реальных условиях рекомендуется средствами конфигурации определить возможные действия пользователей на различных узлах таким образом, чтобы исключить или минимизировать вероятность возникновения коллизий. Основным путем является определения средствами конфигурации "ответственного" узла за каждый ведущий объект в распределенной ИБ и ограничение всем остальным возможности его редактирования и удаления. Определение "ответственных" должно происходить исходя из логики работы предприятия. Очевидно, что многие виды объектов можно разрешить изменять только в центральной ИБ (например, список складов). Для многих объектов можно рекомендовать средствами встроенного языка установить возможность изменения только на той ИБ, на которой они созданы, например для документов.

Параметры миграции

С помощью настройки параметров миграции можно ограничивать области распространения изменений объектов. Настройка параметров миграции происходит по видам "ведущих" объектов. То есть для каждого вида "ведущих" объектов можно определить конкретную настройку параметров миграции. В настройке параметров миграции объектов ведущую роль играет выбор того или иного варианта области распространения изменений объектов данного вида. Существуют три варианта настройки области распространения:

Все информационные базы. Данный вариант настройки используется по умолчанию для всех объектов. В этом случае любые изменения объектов данного типа будут распространяться по всем узлам распределенной ИБ. Этот вариант обеспечивает полную синхронизацию объектов данного вида во всей распределенной ИБ. Очевидно, что этот вариант наиболее прост для конфигурирования.

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

Место создания и центр. При таком варианте настройки области распространения объектов существенную роль играет понятие места создания объекта. Местом создания объекта считается ИБ, в которой был создан конкретный объект. Естественно, что различные объекты одного вида могут быть созданы в различных ИБ. Однако место создания объекта может быть определено не для всех видов "ведущих" объектов. Для таких объектов как константы, календари или корректные проводки место создания не определено. Поэтому для этих видов объектов вариант настройки "Место создания и центр" не может быть установлен.

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

В случае выбора области распространения "Место создания и центр", для вида объекта можно задать перечень периферийных узлов распределенной ИБ, которые дополнительно включаются в область распространения всех объектов данного вида. Этот перечень задается как список кодов периферийных ИБ, разделенный запятыми. При задании кодов ИБ допускается использование символов-заменителей '*'. Символ-заменитель должен завершать последовательность символов, образующих код одной или нескольких периферийных ИБ. Таким образом, "A*" представляет собой обозначение всех периферийных ИБ, коды которых начинаются символом 'А'. Последовательность "A*B" является ошибочной, так как символ '*' не завершает последовательность символов, представляющих код периферийной ИБ.

Кроме того, как отмечалось выше, дополнительной возможностью управлять распространением изменений объектов в версии 7.7 системы 1С:Предприятие является особый вид периферийных ИБ, которые получают изменения из центральной ИБ, а сами информацию о сделанных в них изменениях не передают. Для создания периферийной ИБ такого рода, надо при ее инициализации указать признак "Только получатель".

Отдельно стоит рассмотреть случай, когда параметры миграции объектов изменяются в процессе изменения конфигурации уже работающей системы. Изменения параметров миграции для каждого из объектов производится независимо от других. То есть, Конфигуратор не отслеживает ссылки между объектами при настройке параметров миграции. Таким образом, при определенных вариантах настройки параметров миграции у некоторых объектов могут появиться ссылки, указывающие "никуда". Ответственность за сохранение ссылочной целостности в распределенных ИБ возлагается на лицо, занимающееся конфигурированием системы. Общим правилом настройки параметров миграции является определение области миграции для конкретного вида объектов равной более широкой, чем область миграции ссылающихся на него объектов. Например, для справочника область миграции должна быть определена не уже, чем области миграции документов и справочников, в которых есть реквизиты типа "справочник" данного вида. Если, например, измерение регистра имеет тип "справочник" данного вида, то область миграции справочника должна покрывать области миграции всех документов, которые могут записать движения данного регистра.

При изменении параметров миграции того или иного объекта система старается привести имеющиеся данные в соответствие с новыми параметрами. Общим принципом здесь является то, что при изменении параметров миграции объекты никогда ни в каком узле распределенной ИБ не удаляются. Даже в том случае, если в соответствии с вновь установленными параметрами миграции их там быть не должно. Изменения производятся лишь в таблице регистрации изменений. Рассмотрим случаи изменения параметров миграции объектов подробнее.

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

Следующий случай - это смена области распространения "Место создания" на варианты "Все информационные базы" или "Место создания и центр". В этом случае в таблицу регистрации изменений заносятся записи для передачи всех объектов, для которых текущая ИБ является местом создания во все ИБ, в которые должны передаваться изменения в соответствии с вновь заданной настройкой. В случае, если такая смена производится для объектов, для которых место создания не определено (константы, календари, корректные проводки), то записи в таблицу регистрации изменений будут произведены только в центральной ИБ. Этими двумя вариантами и ограничиваются возможные случаи изменения параметров миграции для такого рода объектов. Все остальные случаи возможны только для тех объектов, для которых место создания можно определить.

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

Последний и самый сложный случай - это изменение области распространения объектов с "Все информационные базы" на "Место создания и центр" или изменение списка дополнительных ИБ в варианте "Место создания и центр". Действия, производимые в данном случае различаются в зависимости от того, производятся они в центральной ИБ или в периферийной. В центральной ИБ для каждой из периферийных ИБ, не попавших в новый перечень дополнительно включаемых в область распространения, выполняется удаление из таблицы регистрации изменений записей соответствующих данному виду объектов, но только для тех объектов, для которых эта периферийная ИБ не является местом создания. Затем определяется список периферийных ИБ, попавших в список дополнительно включаемых в область распространения, но ранее в него не входивших. Естественно, что в случае, если предыдущим вариантом настройки области распространения было "Все информационные базы", то этот список окажется пустым. Затем, как и в предыдущем случае, производится обход всех объектов данного вида и для каждого из объектов в таблицу регистрации изменений вносятся записи для передачи объекта в каждую из попавших в список периферийных ИБ, за исключением ИБ места создания объекта.

Проблемы конфигурирования и администрирования

При разработке конфигурации для распределенной ИБ проявляется ряд объективно существующих проблем, которые решаются как средствами конфигурации, так и административными решениями.

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

Более сложной проблемой является ситуация, когда возникает необходимость использования некоторого нового объекта в двух и более узлах одновременно, до осуществления передачи данных. Например, новый товар должен быть введен и на центральной ИБ и на периферийной. Важно понимать, что созданный ведущий объект системы 1С:Предприятие обладает некоторой сущностью - внутренним идентификатором, который уникален во всей распределенной системе. То есть один и тот же объект не может быть введен в двух узлах. Даже при полном соответствии кодов, номеров и всех данных это будут два разных объекта. Такой принцип необходим для четкой работы системы со всех точек зрения.

Заметим, что возможные варианты ввода двух объектов и затем автоматической замены на центральной ИБ всех ссылок на один из объектов, достаточно сложны в реализации и весьма ненадежны.

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

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

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

Еще одна проблема, с которой приходится сталкиваться при конфигурировании распределенной ИБ, это правильное поддержание механизмов учета компонент при неполной миграции объектов. Следует учитывать, что итоги оперативного и бухгалтерского учета не являются самостоятельными объектами. Они не переносятся, а рассчитываются на основании перенесенных движений регистров и проводок. Движения регистров и проводки переносятся соответственно только вместе с документами. Таким образом, для правильного состояния итогов на некоторой ИБ, на нее должны переноситься все документы, осуществляющие движения регистров или записывающие проводки влияющие на эти итоги. С другой стороны, это не означает, что переноситься должны все документы, записывающие движения конкретного регистра и проводки. Например, если на периферийной ИБ вводятся документы, выполняющие движения по одному складу, и итоги регистра учета товарного запаса в данной ИБ нужны только по данному складу, то, разумеется, в данном узле будет достаточно наличия всех документов выполняющих движения регистров по данному складу. Это достигается установкой параметра миграции "Место создания и центр".

Данная статья предназначена для начинающих программистов, которые никогда не работали с потоками, и хотели бы узнать основы работы с ними. Желательно, чтоб читатель знал основы ООП и имел какой-нибудь опыт работы в Delphi.

Для начала давайте определимся, что под словом "поток" я подразумеваю именно Thread, который еще имеет название "нить". Нередко встречал на форумах мнения, что потоки не нужны вообще, любую программу можно написать так, что она будет замечательно работать и без них. Конечно, если не делать ничего серьёзней "Hello World" это так и есть, но если постепенно набирать опыт, рано или поздно любой начинающий программист упрётся в возможности "плоского" кода, возникнет необходимость распараллелить задачи. А некоторые задачи вообще нельзя реализовать без использования потоков, например работа с сокетами, COM-портом, длительное ожидание каких-либо событий, и т.д.

Всем известно, что Windows система многозадачная. Попросту говоря, это означает, что несколько программ могут работать одновременно под управлением ОС. Все мы открывали диспетчер задач и видели список процессов. Процесс - это экземпляр выполняемого приложения. На самом деле сам по себе он ничего не выполняет, он создаётся при запуске приложения, содержит в себе служебную информацию, через которую система с ним работает, так же ему выделяется необходимая память под код и данные. Для того, чтобы программа заработала, в нём создаётся поток. Любой процесс содержит в себе хотя бы один поток, и именно он отвечает за выполнение кода и получает на это процессорное время. Этим и достигается мнимая параллельность работы программ, или, как её еще называют, псевдопараллельность. Почему мнимая? Да потому, что реально процессор в каждый момент времени может выполнять только один участок кода. Windows раздаёт процессорное время всем потокам в системе по очереди, тем самым создаётся впечатление, что они работают одновременно. Реально работающие параллельно потоки могут быть только на машинах с двумя и более процессорами.

Для создания дополнительных потоков в Delphi существует базовый класс TThread, от него мы и будем наследоваться при реализации своих потоков. Для того, чтобы создать "скелет" нового класса, можно выбрать в меню File - New - Thread Object, Delphi создаст новый модуль с заготовкой этого класса. Я же для наглядности опишу его в модуле формы. Как видите, в этой заготовке добавлен один метод - Execute. Именно его нам и нужно переопределить, код внутри него и будет работать в отдельном потоке. И так, попробуем написать пример - запустим в потоке бесконечный цикл:

Код

TNewThread = class(TThread)
private
{ Private declarations }
protected
procedure Execute; override;
end;


var
Form1: TForm1;

implementation

{$R *.dfm}

{ TNewThread }

procedure TNewThread.Execute;
begin
while true do {ничего не делаем};
end;

procedure TForm1.Button1Click(Sender: TObject);
var
NewThread: TNewThread;
begin
NewThread:=TNewThread.Create(true);
NewThread.FreeOnTerminate:=true;
NewThread.Priority:=tpLower;
NewThread.Resume;
end;

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

Код

NewThread:=TNewThread.Create(true);

тут мы создали экземпляр класса TNewThread. Конструктор Create имеет всего один параметр - CreateSuspended типа boolean, который указывает, запустить новый поток сразу после создания (если false), или дождаться команды (если true).

Код

New.FreeOnTerminate := true;

свойство FreeOnTerminate определяет, что поток после выполнения автоматически завершится, объект будет уничтожен, и нам не придётся его уничтожать вручную. В нашем примере это не имеет значения, так как сам по себе он никогда не завершится, но понадобится в следующих примерах.

Код

NewThread.Priority:=tpLower;

Свойство Priority, если вы еще не догадались из названия, устанавливает приоритет потока. Да да, каждый поток в системе имеет свой приоритет. Если процессорного времени не хватает, система начинает распределять его согласно приоритетам потоков. Свойство Priority может принимать следующие значения:

tpTimeCritical - критический

tpHighest - очень высокий

tpHigher - высокий

tpNormal - средний

tpLower - низкий

tpLowest - очень низкий

tpIdle - поток работает во время простоя системы

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

Код

NewThread.Resume;

Ну и собственно, запуск потока.

Думаю, теперь вам понятно, как создаются потоки. Заметьте, ничего сложного. Но не всё так просто. Казалось бы - пишем любой код внутри метода Execute и всё, а нет, потоки имеют одно неприятное свойство - они ничего не знают друг о друге. И что такого? - спросите вы. А вот что: допустим, вы пытаетесь из другого потока изменить свойство какого-нибудь компонента на форме. Как известно, VCL однопоточна, весь код внутри приложения выполняется последовательно. Допустим, в процессе работы изменились какие-то данные внутри классов VCL, система отбирает время у основного потока, передаёт по кругу остальным потокам и возвращает обратно, при этом выполнение кода продолжается с того места, где приостановилось. Если мы из своего потока что-то меняем, к примеру, на форме, задействуется много механизмов внутри VCL (напомню, выполнение основного потока пока "приостановлено"), соответственно за это время успеют измениться какие-либо данные. И тут вдруг время снова отдаётся основному потоку, он спокойно продолжает своё выполнение, но данные уже изменены! К чему это может привести - предугадать нельзя. Вы можете проверить это тысячу раз, и ничего не произойдёт, а на тысяча первый программа рухнет. И это относится не только к взаимодействию дополнительных потоков с главным, но и к взаимодействию потоков между собой. Писать такие ненадёжные программы конечно нельзя.
Синхронизации потоков
Если вы создали шаблон класса автоматически, то, наверное, заметили комментарий, который дружелюбная Delphi поместила в новый модуль. Он гласит: "Methods and properties of objects in visual components can only be used in a method called using Synchronize". Это значит, что обращение к визуальным компонентам возможно только путём вызова процедуры Synchronize. Давайте рассмотрим пример, но теперь наш поток не будет разогревать процессор впустую, а будет делать что-нибудь полезное, к примеру, прокручивать ProgressBar на форме. В качестве параметра в процедуру Synchronize передаётся метод нашего потока, но сам он передаётся без параметров. Параметры можно передать, добавив поля нужного типа в описание нашего класса. У нас будет одно поле - тот самый прогресс:

Код

TNewThread = class(TThread)
private
Progress: integer;
procedure SetProgress;
protected
procedure Execute; override;
end;
...

procedure TNewThread.Execute;
var
i: integer;
begin
for i:=0 to 100 do
begin
sleep(50);
Progress:=i;
Synchronize(SetProgress);
end;
end;

procedure TNewThread.SetProgress;
begin
Form1.ProgressBar1.Position:=Progress;
end;

Вот теперь ProgressBar двигается, и это вполне безопасно. А безопасно вот почему: процедура Synchronize на время приостанавливает выполнение нашего потока, и передаёт управление главному потоку, т.е. SetProgress выполняется в главном потоке. Это нужно запомнить, потому что некоторые допускают ошибки, выполняя внутри Synchronize длительную работу, при этом, что очевидно, форма зависает на длительное время. Поэтому используйте Synchronize для вывода информации - то самое двигание прогресса, обновления заголовков компонентов и т.д.

Вы наверное заметили, что внутри цикла мы используем процедуру Sleep. В однопоточном приложении Sleep используется редко, а вот в потоках его использовать очень удобно. Пример - бесконечный цикл, пока не выполнится какое-нибудь условие. Если не вставить туда Sleep мы будем просто нагружать систему бесполезной работой.

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

Код

const
PROGRESS_POS = WM_USER+1;

В объявление класса формы добавим новый метод, а затем и его реализацию:

Код

TForm1 = class(TForm)
Button1: TButton;
ProgressBar1: TProgressBar;
procedure Button1Click(Sender: TObject);
private
procedure SetProgressPos(var Msg: TMessage); message PROGRESS_POS;
public
{ Public declarations }
end;
...

procedure TForm1.SetProgressPos(var Msg: TMessage);
begin
ProgressBar1.Position:=Msg.LParam;
end;

Теперь мы немного изменим, можно сказать даже упростим, реализацию метода Execute нашего потока:

procedure TNewThread.Execute;
var
i: integer;
begin
for i:=0 to 100 do
begin
sleep(50);
SendMessage(Form1.Handle,PROGRESS_POS,0,i);
end;
end;

Используя функцию SendMessage, мы посылаем окну приложения сообщение, один из параметров которого содержит нужный нам прогресс. Сообщение становится в очередь, и согласно этой очереди будет обработано главным потоком, где и выполнится метод SetProgressPos. Но тут есть один нюанс: SendMessage, как и в случае с Synchronize, приостановит выполнение нашего потока, пока основной поток не обработает сообщение. Если использовать PostMessage этого не произойдёт, наш поток отправит сообщение и продолжит свою работу, а уж когда оно там обработается - неважно. Какую из этих функций использовать - решать вам, всё зависит от задачи.

Вот, в принципе, мы и рассмотрели основные способы работы с компонентами VCL из потоков. А как быть, если в нашей программе не один новый поток, а несколько? И нужно организовать работу с одними и теми же данными? Тут нам на помощь приходят другие способы синхронизации. Один из них мы и рассмотрим. Для его реализации нужно добавить в проект модуль SyncObjs.
Критические секции
Работают они следующим образом: внутри критической секции может работать только один поток, другие ждут его завершения. Чтобы лучше понять, везде приводят сравнение с узкой трубой: представьте, с одной стороны "толпятся" потоки, но в трубу может "пролезть" только один, а когда он "пролезет" - начнёт движение второй, и так по порядку. Еще проще понять это на примере и тем же ProgressBar'ом. Итак, запустите один из примеров, приведённых ранее. Нажмите на кнопку, подождите несколько секунд, а затем нажмите еще раз. Что происходит? ProgressBar начал прыгать. Прыгает потому, что у нас работает не один поток, а два, и каждый из них передаёт разные значения прогресса. Теперь немного переделаем код, в событии onCreate формы создадим критическую секцию:

Код

var
Form1: TForm1;
CriticalSection: TCriticalSection;

...

procedure TForm1.FormCreate(Sender: TObject);
begin
CriticalSection:=TCriticalSection.Create;
end;

У TCriticalSection есть два нужных нам метода, Enter и Leave, соответственно вход и выход из неё. Поместим наш код в критическую секцию:

Код

procedure TNewThread.Execute;
var
i: integer;
begin
CriticalSection.Enter;
for i:=0 to 100 do
begin
sleep(50);
SendMessage(Form1.Handle,PROGRESS_POS,0,i);
end;
CriticalSection.Leave;
end;

Попробуйте запустить приложение и нажать несколько раз на кнопку, а потом посчитайте, сколько раз пройдёт прогресс. Понятно, в чем суть? Первый раз, нажимая на кнопку, мы создаём поток, он занимает критическую секцию и начинает работу. Нажимаем второй - создаётся второй поток, но критическая секция занята, и он ждёт, пока её не освободит первый. Третий, четвёртый - все пройдут только по-очереди.

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

В этой небольшой статье рассмотрены не все способы синхронизации, есть еще события (TEvent), а так же объекты системы, такие как мьютексы (Mutex), семафоры (Semaphore), но они больше подходят для взаимодействия между приложениями. Остальное, что касается использования класса TThread, вы можете узнать самостоятельно, в help'е всё довольно подробно описано. Цель этой статьи - показать начинающим, что не всё так сложно и страшно, главное разобраться, что есть что. И побольше практики - самое главное опыт!

Поскольку качество видео на DVD носителях превосходное, то вопрос защиты от копирования стоит острее, чем защита от копирования фильмов на VCD и видеокассета. Может показаться, что вообще невозможно предотвратить незаконное копирование как цифровых так и аналоговых форматов и в любом случае найдутся "умельцы". Но все же принимаются меры. Какие мы вам расскажем далее.

Механизм защиты от копирования DVD

Во-первых, давайте посмотрим сколько дорожек доступно для копирования в DVD системе. Первая дорожка содержит необрабатываемые цифровые данные, считываемые с DVD привода, в возможные пиратские приборы встроены DVD видео декодеры, которые не будут принимать меры против защиты от копирования на дорожках 2 и 3. Система content scramble system (CSS) не позволяет добраться до содержания 2 и 3 дорожки без чтения первой. Сигнал со второй дорожки идет в аналоговом телевизионном формате NTSC или PAL. Поскольку VHS видеомагнитофоны очень распространены на сегодняшний день, то проще всего сделать копию в этом формате с DVD качеством.

content scramble system (система защиты от копирования)

основной целью CSS является защита содержания DVD от пиратского взлома и копирования через защиту от DVD видео декодеров и дисководов перезаписываемых дисков. Чтобы воспроизвести защищенный авторским правом материал с DVD ROM диска нужно согласие владельца авторского права, для чего и создана система content scramble. Три кода нанесены один за другим, что значит, что второй ключ может быть получен только при обладании первым, а третий только через получение второго. После этого, сжатое содержание может быть развернуто посредством третьего ключа. То есть для полного доступа нужно иметь три ключа. Конечно, алгоритм расшифровки можно получить через подписание документов, разрешающих тиражирование. Для предотвращения копирования с/на цифровые носители в среде персонального компьютера, предпринята попытка идентификации и шифровки данных. В среде персонального компьютера, для копирования необходимо два "компонента": DVD ROM привод и карта декодера, подсоединенные к PC шине. Поскольку данные с PC шины легко скопировать, то DVD ROM должен сам проверять законность получателя перед отправки данных. Также, для предотвращения воспроизведения нелегально скопированного материала, карта декодера должна проверять законность отправителя данных. Поэтому необходима обоюдная идентификация. А для предотвращения подмены диска после идентификации, DVD ROM привод должен периодически менять ключ шифра перед отсылкой.

Macrovision & CGMS/A (copy generation management system/analog (макровижн и система управления тиражированием/аналоговая))

Макровижн основан на различиях в работе видеомагнитофонов и телевизоров. Защита от копирования в этом случае состоит из двух элементов: AGC [Automatic Gain Control] автоматическая регулировка усиления и "полосатого" кода. Система AGC в телевизоре спроектирована так, что медленно реагирует на изменения, та же, схема, которая встроена в видеомагнитофоны, должна мгновенно реагировать на изменения. Именно это различие и лежит в основе системы. Суть в том, что макровижн изменяет сигнал так, что при воспроизведении картинка будет хорошей, а при записи на копии будут множественные качественные изменения. Что касается "полосатого" кода, то при воспроизведении он не оказывает никакого влияния на качество изображения, при просмотре копии на картинке появится ужасная вертикальная полосность.

В то время как макровижн направлен на устранение пиратских копий, CGMS/A направлена на контроль записи легальных копий. Информация CGMS/A вложена в выходящий видео сигнал. Для работы CGMS/A ( то есть для возможности сделать легальную копию) необходимо, чтобы записывающее оборудование распознавало CGMS. CGMS кодирует информацию на линии 21 системы NTSC, при этом CGMS имеет приоритет над антикопировальными сигналами макровижн, записываемых на ту же линию.

CGMS/D (система управления тиражированием/цифровая)

Эта система основана на стандарте IEEE 1394 и предназначена для ограничения ("copy once"- одна копия) и запрещение ("copy never"- запрещение копирования) создания цифровых копий. Цифровые приборы, такие, например как DVD плеер и цифровой TV, будут обмениваться ключами и идентификационными подтверждениями перед установлением канала. DVD плеер шифрует видео сигнал при отправке, а получающий прибор расшифровывает его. Пишущие цифровые приборы не смогут получать сигнал при внутренней маркировке "copy never", а при маркировке "copy once"- сделают копию и изменят маркер на "copy never". CGMS/D спроектирован для следующего поколения цифровых ТВ и видео рекордеров. Для этой системы нужны DVD проигрыватели нового поколения с цифровыми соединениями.
Код региона (код места)
Смысл этого кодирования состоит в том, что киностудии пожелали ввести дополнительную кодировку поскольку в большинстве случаев фильмы вышедшие на DVD в одной стране еще идут на киноэкране другой страны. Для увеличения доходов от проката фильмов для разных географических регионов устанавливаются разные коды. Этот код будет встраиваться в DVD проигрыватель на основании региона в котором он был продан. Это означает, что диски купленные в одной стране могут не проигрываться в другой.

Регионы разбиты так. Каждый диск будет идентифицироваться по цифре. Если диск разрешен к проигрыванию в более чем одном регионе, то соответственно и цифр будет больше.
1: Канада, США, Территории США.
2: Япония, Европа, Южная Африка, Средний Восток (включая Египет)
3: Южно-восточная Азия, Восточная Азия (включая Гонконг)
4: Австралия, Новая Зеландия, Центральная Америка, Мексика, Южная Америка, Карибы.
5: Бывший Советский Союз, Индия и Африка, Северная Корея, Монголия
6: Китай

В этом статье обсуждаются особенности работы со скриптами JavaScript в PHP. В отличие от PHP, скрипты JavaScript выполняются на машине клиента, в то время как PHP серверный язык программирования. В отличие, от технологии Java или ASP.NET он не имеет в своём составе средств для работы на клиентской стороне. Поэтому для создания эффективных Web-приложений необходимо комбинировать PHP и JavaScript скрипты. Существует две возможности такого взаимодействия: передача переменных из JavaScript в PHP и динамическое формирование скриптов JavaScript средствами PHP.

Передача переменных из JavaScript в PHP

Одной из распространенной задачей является определение разрешение экрана и глубину цвета монитора посетителя страницы средствами JavaScript с последующей передачей этих данные в PHP-скрипт.

Это довольно часто встречающаяся задача, особенно при написании счетчиков посещений и создании "динамического дизайна".

Скрипт JavaScript, выполняющий необходимые действия, размещен файле index.html, содержимое которого приведено в нижеследующем листинге:

Файл index.html

Код

<Script Language="JavaScript">
var height=0;
var width=0;
colorDepth = screen.colorDepth;
if (self.screen)
{
width = screen.width
height = screen.height
}
else if (self.java)
{
var jToolKit = java.awt.Toolkit.getDefaultToolkit();
var scrsize = jToolKit.getScreenSize();
width = scrsize.width;
height = scrsize.height;
}
if (width > 0 && height > 0)
{
// Производим перенаправление на скрипт counter.php, передавая в
// переменной scrsize строку, содержащую значения width,
// height и colorDepth.
window.location.href = "http://localhost/view.php?
width=" + width +
"&height=" + height +
"&color=" + colorDepth;
} else exit();
</Script>

После выполнения этого кода происходит автоматический переход на страницу view.php, в котором происходит вывод разрешения экрана и глубины цветопередачи в окно браузера (см. листинг ниже).

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

Файл view.php

PHP - Код

echo "Ширина : ".$_GET['width'];
  echo "Высота : ".$_GET['height'];
  echo "Цветовое <sup>разрешение</sup> : ".$_GET['color'];

Как видно, работа с данными из JavaScript, аналогична работе с данными, отправляющихся методом GET.