Динамические структуры данных 1 страница

End.

Begin

Implementation

Interface

Модульная организация программ

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

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

8.1. Состав модуля и его разработка

Модуль имеет следующую структуру:

Unit <имя>;

<интерфейсная часть>

<исполняемая часть>

<инициирующая часть> }

Здесь

Unit - кодовое слово (англ.- модуль), начинающее заголовок модуля;

<имя> - имя модуля (правильный идентификатор);

Interface - кодовое слово, начинающее интерфейсную часть модуля;

Implementation - кодовое слово (англ.-выполнение), начинающее исполняемую часть;

Begin - кодовое слово, начинающее инициирующую часть; (часть модуля Begin <инициирующая часть> необязазтельна);

End - признак конца модуля.

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

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

Если, например, имеем заголовок Unit Global; то исходный текст соответствующего модуля должен размещаться в дисковом файле Global.pas. Имя модуля служит для его связи с другими специальными модулями и основной программой. Эта связь устанавливается специальным предложением

Uses <список модулей>

Здесь Uses - кодовое слово (англ.- использует);

<список модулей> - список модулей, с которыми устанавливается связь; элементами списка являются имена модулей, отделяемые друг от друга запятыми, например:

Uses CRT, Graph, Global;

Если предложение Uses... используется, оно должно открывать раздел описаний основной программы или следовать сразу за кодовым словом Interface в модуле.

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

Unit Cmplx;

Interface

Type

complex = record

re, im:real

end;

Procedure AddC(x,y:complex; var z:complex);

Procedure MulC(x,y:complex; var z:complex);

Если теперь в основной программе написать предложение Uses Cmplx; то в программе станут доступными тип Complex и две процедуры - AddC и MulC из модуля Cmplx.

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

Unit Cmplx;

Interface

Type

complex = record

re, im:real

end;

Procedure AddC(x,y:complex; var z:complex);

Implementation

Procedure AddC;

Begin

z.re:=x.re+y.re;

z.im:=x.im+y.im

End;

End.

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

Пример:

Unit FileText;

Interface

Procedure Print(s:string);

Implementation

Var f:text;

Const Name='Output.txt';

Procedure Print;

Begin

Writeln(f,s)

End;

{Hачало иницииpующей части}

Begin

Assign(f,name);

Rewrite(f);

{Конец иницииpующей части}

End.

8.2. Компиляция и доступ к объявленным в модуле объектам

В среде Borland-Паскаля имеются средства, управляющие способами компиляции модулей и облегчающие разработку крупных программных проектов. Определены три режима компиляции: Compile, Make, Build. Режимы отличаются только способом связи компилируемого модуля или компилируемой основной программы с другими модулями, объявленными в предложении Uses.

При компиляции модуля или основной программы в режиме Compile все упоминающиеся в предложении Uses модули должны быть предварительно откомпилированы и результаты их компиляции должны быть помещены в одноименные файлы с расширением.TPU. Например, если в программе (в модуле) имеется предложение Uses Global; то на диске в каталоге, объявленном опцией Unit Directories, уже должен находиться файл Global.Tpu. Файл с расширением.Tpu (от англ. Turbo-Pascal Unit) создается в результате компиляции модуля.

В режиме Make компилятор проверяет наличие Tpu-файлов для каждого объявленного модуля. Если какой-либо из файлов не обнаружен, система пытается отыскать одноименный файл с расширением.Pas, то есть файл с исходным текстом модуля, и, если Pas-файл найден, приступает к его компиляции. Кроме того, в этом режиме система следит за возможными изменениями исходного текста любого используемого модуля. Если внесены какие-либо изменения в Pas-файл (исходный текст модуля), то независимо от того, есть ли уже в каталоге соответствующий Tpu-файл или нет, система осуществляет его компиляцию перед компиляцией основной программы. Более того, если изменения внесены в интерфейсную часть модуля, то будут перекомпилированы также и все другие модули, обращающиеся к нему. Режим Make, таким образом, существенно облегчает процесс разработки крупных программ с множеством модулей: программист избавляется от необходимости следить за соответствием существующих Tpu-файлов и их исходного текста, так как система делает это автоматически.

В режиме Build существующие Tpu-файлы игнорируются, и система пытается отыскать (и компилировать) соответствующий Pas-файл для каждого объявленного в Uses модуля. После компиляции в режиме Build программист может быть уверен в том, что учтены все сделанные им изменения в любом из модулей. Подключение модулей к основной программе и их возможная компиляция осуществляются в порядке их объявления в предложении Uses. При переходе к очередному модулю система предварительно отыскивает все модули, на которые он ссылается. Ссылки модуля друг на друга могут образовывать древовидную структуру любой сложности, однако запрещается явное или косвенное обращение модуля к самому себе.

Пусть, например, создан модуль, реализующий арифметику комплексных чисел.

Unit Cmplx;

Interface

Type

complex = record

re, im:real

end;

Procedure AddC(x,y:complex; var z:complex);

Procedure SubC(x,y:complex; var z:complex);

Procedure MulC(x,y:complex; var z:complex);

Procedure DivC(x,y:complex; var z:complex);

Const c:complex=(re:0.1;im:-1);

Implementation

Procedure AddC;

Begin

z.re:=x.re+y.re;

z.im:=x.im+y.im

End;

Procedure SubC;

Begin

z.re:=x.re-y.re;

z.im:=x.im-y.im

End;

Procedure MulC;

Begin

z.re:=x.re*y.re - x.im*y.im;

z.im:=x.re+y.im - x.im*y.re

End;

Procedure DivC;

Var zz:real;

Begin

zz:=sqr(y.re)+sqr(y.im);

z.re:=(x.re*y.re+x.im*y.im)/zz;

z.im:=(x.re*y.im-x.im*y.re)/zz

End;

End.

Текст этого модуля нужно поместить в файл Cmplx.pas. Теперь можно написать программу.

Program Ex18;

Uses Cmplx;

Var a,b,c:complex;

Begin

a.re:=1; a.im:=1;

b.re:=1; b.im:=2;

AddC(a,b,c);

Writeln('Сложение:', c.re:5:1, c.im:5:1,'i');

SubC(a,b,c);

Writeln('Вычитание:', c.re:5:1, c.im:5:1,'i');

MulC(a,b,c);

Writeln('Умножение:', c.re:5:1, c.im:5:1,'i');

DivC(a,b,c);

Writeln('Деление:', c.re:5:1, c.im:5:1,'i');

End.

Программа даст следующие результаты:

Сложение: 2.0 3.0i

Вычитание: 0.0 -1.0i

Умножение: -1.0 2.0i

Деление: 0.6 0.2i

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

8.3. Стандартные модули

В Паскале имеется восемь стандартных модулей, в которых содержится большое число разнообразных типов, констант, процедур и функций. Этими модулями являются System, Dos, Crt, Printer, Graph, Overlay, Turbo3 и Graph3. Модули Graph, Turbo3 и Graph3 содержатся в одноименных Tpu-файлах, остальные входят в состав библиотечного файла Turbo.tpl. Лишь один модуль System подключается к любой Паскалевской программе автоматически, все остальные становятся доступны только после указания их имен в списке, следующем за кодовым словом Uses.

В модуль System входят все процедуры и функции стандартного Паскаля, а также встроенные процедуры и функции Borland-Паскаля, которые не вошли в другие стандартные модули (например, Inc, Dec, Getdir и т.п.).

Модуль Printer упрощает вывод текстов на принтер. В нем определяется файловая переменная Lst типа Text, которая связывается с логическим устройством Prn. После подключения модуля может быть выполнена, например, такая программа:

Uses Printer;

Begin

Writeln(lst,'Паскаль')

End.

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

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

В модуле Dos собраны процедуры и функции, открывающие доступ Паскалевским программам ко всем средствам операционной системы.

Блоки модуля Overlay понадобятся при разработке громоздких программ с перекрытиями.

Два библиотечных модуля Turbo3 и Graph3 введены для совместимости с ранней версией 3.0 системы Турбо-Паскаль.

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

Основные концепции модульного программирования:

- каждый модуль реализует единственную независимую функцию;

- каждый модуль имеет единственную точку входа/выхода;

- размер модуля по возможности стремятся минимизировать;

- каждый модуль может быть спроектирован и закодирован различными членами бригады программистов и может быть отдельно протестирован;

- вся система построена из модулей.

8.4. Оверлейная структура программ

Известно, что максимальный размер модуля не может превышать 64Кбайт, однако количество модулей не ограничено, что дает возможность разрабатывать весьма крупные программы, занимающие, например, всю доступную оперативную память (3-4Мбайт). Однако в некоторых случаях и этот объем может оказаться недостаточным.

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

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

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

BorlandPascal управляет оверлеями на уровне модулей; это наименьшая часть программы, которую можно сделать оверлейной. Когда оверлейная программа компилируется, BorlandPascal генерирует оверлейный файл (с расширением.ovr) в дополнение к выполнимому файлу (с расширением.exe)..exe файл содержит статическую (неперекрываемую) часть программы..ovr файл содержит все модули, которые будут перекачиваться в/из памяти во время выполнения программы.

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

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

Пусть, например, программа состоит из главной части MAIN и двух модулей А и В. Пусть также LM, LA и LB - длина соответственно главной части и обоих модулей, причем LA>LB. Тогда неоверлейная программа займет в памяти LM+LA+LB байт, в то время как оверлейная программа лишь LM+LA.

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

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

Работа оверлейных программ обеспечивается с помощью процедур и функций библиотечного модуля Ovelay, входящего в библиотечный файл Turbo.tpu.

Оверлейные программы нужно создавать в такой последовательности:

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

2) В главной части программы необходимо указать с помощью директив компилятора вида {$O <имя>} те модули, которые будут оверлейными, например:

Program Main;

Uses

CRT, DOS< Graph, Overlay, UnitA, UnitB;

{$O DOS}

{$O UnitA}

{$O UnitB}

Из всех стандартных библиотечных модулей только один модуль DOS может быть оверлейным, остальные модули (CRT, Graph, Printer и т.д.) не могут объявляться оверлейными.

3) Необходимо предусмотреть перед первым по логике работы программы обращением к какому-либо оверлейному модулю вызов процедуры инициализации оверлея OvrInit.

Процедура OvrInit. Инициализирует оверлейный файл; формат обращения:

OvrInit(<имя>)

Здесь <имя> - выражение типа String, означающее имя файла с оверлейной частью программы.

4) В начале главной программы и каждого оверлейного модуля необходимо поместить директивы компилятора {$O+} и {$F+}, после чего следует откомпилировать программу на диск.

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

Проиллюстрируем сказанное. Пусть файл с главной частью программы называется Main.pas; в программе используются два оверлейных модуля, помещаемые в файлы UnitA.pas и UnitB.pas.

Program Ex19;

{Текст главной пpогpаммы нужно поместить в файл Main.pas}

{$F+,O+}

Uses Overlay,UnitA, UnitB;

{$O UnitA}

{$O UnitB}

Begin

OvrInit('Main.Ovr');

SubA

End.

Unit UnitA;

{Текст модуля нужно поместить в файл UnitA.pas}

{$F+,O+}

InterFace

Uses UnitB;

Procedure SubA;

Implementation

Procedure SubA;

Const

st='Работает модуль ';

Begin

writeln (st,'A');

SubB(st)

End;

End.

Unit UnitB;

{Текст модуля нужно поместить в файл UnitB.pas}

{$F+,O+}

InterFace

Procedure SubB(s:string);

Implementation

Procedure SubB;

Begin

writeln (s,'B');

End;

End.

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

Процедура OVRINT (<имя>) – инициирует оверлейный файл.

<Имя> – выражение типа String, имя файла с оверлейной частью программы.

В этот файл компилятор помещает все оверлейные модули, из него же эти модули загружаются в оверлейный буфер в процессе исполнения программы. Файл с оверлейной частью программы должен размещаться в том же каталоге, что и файл с главной частью (с расширением.EXE). Отметим, что имя оверлейного файла необходимо дополнить расширением.OVR.

Процедура OVRSETBUF (<длина>) – устанавливает размер оверлейного буфера.

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

Функция OVRGETBUF – возвращает значение типа Longint, содержащее текущий размер оверлейного буфера.

Процедура OVRINTEMS – обеспечивает использование расширенной памяти. Если ПК относится к классу IBM PC/AT, в нем имеется расширенная память - Expanded Memory Specificаtion. Можно использовать эту память для размещения в ней оверлейного файла. Поскольку время доступа к расширенной памяти значительно меньше времени чтения с диска, такое размещение увеличивает скорость исполнения оверлейной программы.

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

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

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

8.5. Графический режим работы с использованием стандартного модуля Graph

Стандартные процедуры и функции управления графическим экраном включены в стандартный модуль Graph.Tpu и становятся доступны только после объявления в программе предложения Uses Graph

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

8.5.1. Переход в графический режим и возврат в текстовый

Стандартное состояние ПЭВМ после ее включения, а также к моменту

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

Процедура InitGraph. Инициирует графический режим работы адаптера; формат обращения

InitGraph(<драйвер>,<режим>,<путь>)

Здесь <драйвер> - переменная типа Integer, определяющая тип графического драйвера;

<режим> - переменная типа Integer, определяющая режим работы графического адаптера;

<путь> - выражение типа String, содержащее путь к файлу драйвера.

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

Driver:=detect;

InitGraph(Driver,Regim,'f:\tp\bin');

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

Функция GraphResult. Возвращает значение типа Integer, в котором закодирован результат последнего обращения к графическим процедурам. Если ошибка не обнаружена, значением функции будет 0 (константа отсутствия ошибки имеет имя GrOk), в противном случае

- отрицательное число, указывающее номер ошибки.

Функция GraphErrorMsg. Возвращает значение типа String, в котором по указанному коду ошибки дается соответствующее текстовое сообщение.

Процедура CloseGraph. Прекращает работу адаптера в графическом режиме и восстанавливает текстовый режим работы экрана.

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

Функция GetGraphMode. Возвращает значение типа Integer, в котором содержится код установленного режима работы графического адаптера.

Процедура SetGraphMode. Устанавливает новый режим работы графического адаптера.

Программа иллюстрирует переход из графического режима в текстовый и обратно. Для того, чтобы избежать появления ошибки, необходимо указать каталог, в котором размещен файл egavga.bgi (f:\tp\bgi\), либо скопировать этот файл в каталог, из которого Вы работаете с Паскаль-программой.

Пример:

Program Ex20;

Uses Graph;

Var

Driver, Regim, Error: integer;

Begin

{Инициация гpафического pежима}

Driver:=Detect;

InitGraph(Driver, Regim,'');

Error:=GraphResult;

If Error<>GrOk then writeln(GraphErrorMsg(Error)) else

begin

writeln('That''s the Graphics Mode');

writeln(' Press "Enter"...');

readln;

{Пеpеход в текстовый pежим}

RestoreCrtMode;

writeln('А это текстовый pежим');

readln;

{Возвpат в гpафический pежим}

SetGraphMode (GetGraphMode);

writeln('That''s again the Graphics Mode');

readln;

CloseGraph

end

End.

8.5.2. Координаты и окна, страницы, линии и точки

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

Функции GetX и GetY. Возвращают значения типа Integer, содержащие текущие координаты курсора соответственно по горизонтали и вертикали.

Процедура SetViewPort. Устанавливает прямоугольное окно на графическом экране; формат обращения

SetViewPort(x1,y1,x2,y2,<отсечка>)

Здесь x1,y1 - выражения типа Integer, задающие координаты верхнего левого угла окна;

x2,y2 - выражения типа Integer, задающие координаты нижнего правого угла окна;

<отсечка> - выражение типа Boolean, определяющее "отсечку" не умещающихся в окне элементов изображения.

Координаты задаются всегда относительно левого верхнего угла экрана. Если параметр <отсечка> имеет значение True, элементы изображения, не умещающиеся в пределах окна, отсекаются, в противном случае границы окна игнорируются. Для управления этим параметром можно использовать определенные в модуле константы:

Дата добавления: 2014-12-27