Вопрос по лекции 7, где рассматривается взаимодействие со сторонними программами, в том числе эмуляция нажатия кнопок клавиатуры WshShell.SendKeys. Вопрос в том что во время автоматизации может потребоваться не нажатие клавиатуры, а нажатие кнопок в сообщениях этих программ. Можно вытащить информацию о объекте (кнопке) скажем с помощью AutoIt Info, или ориентироваться скажем на текст на кнопке..., но как на эту кнопку нажать? (без обхода по клавиатуре) |
Сценарии WSH как XML-документы. Схема WS XML
Сценарии WSH как XML-документы. Схема WS XML
До сих пор мы рассматривали простые одиночные файлы сценариев, в которых мог использоваться язык JScript или VBScript. В версии WSH 1.0 это был единственный поддерживаемый тип сценариев, причем используемый язык определялся по расширению файла: js для JScript и vbs для VBScript. Начиная с WSH 2.0 появилась возможность создавать сценарии, в которых можно применять оба языка одновременно. Для таких сценариев в операционной системе регистрируется расширение wsf; wsf-файлы мы будем далее называть просто WS-файлами. Новый тип сценариев (WS-файл) имеет еще несколько важных преимуществ перед одиночными файлами сценариев WSH 1.0:
- поддерживаются вложенные файлы;
- возможен доступ из сценария к внешним мнемоническим константам, которые определены в библиотеках типов используемых объектов ActiveX;
- в одном WS-файле можно хранить несколько отдельных, независимых друг от друга, сценариев;
- сценарий становится самодокументируемым, т. е. вывод информации об использовании сценария и его синтаксисе происходит автоматически.
Понятно, что для обеспечения новых возможностей необходимо иметь больше информации, чем ее может предоставить отдельный сценарий. В самом файле сценария должна присутствовать некоторая дополнительная информация, скажем, имя этого сценария (подобная информация содержится, например, в заголовках HTML-страниц). Другими словами, для сценариев WSH должен использоваться уже некий специальный формат, а не просто отдельные js- или vbs-файлы. В качестве такого формата разработчики Microsoft выбрали язык XML (Extensible Markup Language), который уже использовался ими для определения информационной модели в технологии Windows Script Components (WSC), которая позволяет с помощью языков сценариев создавать и регистрировать полноценные COM-объекты.
Таким образом, теперь сценарии WSH не просто содержат в текстовом виде ActiveX-совместимый сценарий, а являются XML-приложениями, поддерживающими схему WS XML (Windows Script XML), которая, в свою очередь, опирается на схему WSC XML. Поэтому для понимания двух технологий (WSC и WSH) достаточно освоить одну схему XML.
WS-файл рассматривается сервером сценариев как файл с разметкой XML, который должен соответствовать схеме WS XML. Новый тип файла и формат XML обеспечивают более мощную среду для написания сценариев.
Для того чтобы использовать язык XML в сценариях WSH, вовсе не обязательно вникать во все тонкости этого языка, однако основные принципы XML понимать, конечно, нужно.
Основные принципы XML
Проявляемый в настоящее время большой интерес к языку XML объясняется тем, что он предоставляет возможности, позволяющие в текстовой форме описывать структурированные данные. Точнее говоря, XML является метаязыком для создания различных языков разметки, которые способны определять произвольные структуры данных — двоичные данные, записи в базе данных или сценарии. Прежде всего, XML используется в Internet-приложениях при работе браузеров, которые отображают информацию, находящуюся на Web-серверах. При этом пользователю отдельно передаются данные в виде XML-документа, и отдельно — правила интерпретации этих данных для отображения с помощью, например, языков сценариев JScript или VBScript.
Как и HTML, XML является независимым от платформы промышленным стандартом. Полные спецификации XML и связанных с ним языков доступны на официальной странице корпорации World Wide Web Consortium (W3C) по адресу http://www.w3c.org/xml.
Внешне XML-документ похож на HTML-документ, так как XML-элементы также описываются с помощью тегов, то есть ключевых слов. Однако, в отличие от HTML, в XML пользователь может создавать собственные элементы, поэтому набор тегов не является заранее предопределенным. Еще раз повторим, что теги XML определяют структурированную информацию и, в отличие от тегов HTML, не влияют на то, как браузер отобразит эту информацию. Ниже перечислены несколько основных правил формирования корректного XML-документа:
- документ XML состоит из элементов разметки (markup) и непосредственно данных (content);
- все XML-элементы описываются с помощью тегов;
- в заголовке документа с помощью специальных тегов помещается дополнительная информация (используемый язык разметки, его версия и т. д.);
- каждый открывающий тег, который определяет область данных, должен иметь парный закрывающий тег (в HTML некоторые закрывающие теги можно опускать);
- в XML, в отличие от HTML, учитывается регистр символов;
- все значения атрибутов, используемых в определении тегов, должны быть заключены в кавычки;
- вложенность элементов в документе XML строго контролируется.
Рассмотрим теперь структуру и синтаксис WS-файлов, использующих схему WS XML.
Схема WS XML
Синтаксис элементов, составляющих структуру WS-файла, в общем виде можно представить следующим образом:
<element [attribute1="value1" [attribute2="value2" ... ]]> Содержимое (content) </element>
Открывающий тег элемента состоит из следующих компонентов:
- открывающей угловой скобки "<";
- названия элемента, написанного строчными буквами;
- необязательного списка атрибутов со значениями (названия атрибутов пишутся строчными буквами, значения заключаются в двойные кавычки);
- закрывающей угловой скобки ">".
Например, тег начала элемента
<script language="JScript">
имеет имя тега script и определяет атрибут language со значением "JScript". Атрибуты предоставляют дополнительную информацию о соответствующем теге или последующем содержимом элемента. В нашем примере атрибут указывает на то, что содержимым элемента является текст сценария на языке JScript.
Закрывающий тег элемента состоит из следующих компонентов:
- открывающей угловой скобки "<";
- символа "/";
- названия элемента, написанного строчными буквами;
- закрывающей угловой скобки ">".
Таким образом, тег конца элемента не имеет атрибутов, например, </script>.
Если у элемента нет содержимого, то он имеет следующий вид:
<element [attribute1="value1" [attribute2="value2" … ]]/>
То есть в этом случае элемент состоит из следующих компонентов:
- открывающей угловой скобки "<";
- названия элемента, написанного строчными буквами;
- необязательного списка атрибутов со значениями (названия атрибутов пишутся строчными буквами, значения заключаются в двойные кавычки);
- символа "/";
- закрывающей угловой скобки ">".
Пример такого элемента:
<script language="JScript" src="tools.js"/>
Представленная в табл. 9.1 схема WS XML — это модель данных, определяющая элементы и соответствующие атрибуты, а также связи элементов друг с другом и возможную последовательность появления элементов. Также эта схема может задавать значения атрибутов по умолчанию.
<?XML version="1.0" standalone="yes"?> | ||||
<package> | ||||
<job [id="JobID"]> | ||||
<?job debug="true|false"?> | ||||
<runtime> | ||||
<named name="NamedName" helpstring="HelpString" type="string|boolean|simple" required="true|false" /> | ||||
<unnamed name="UnnamedName" helpstring="HelpString" many="true|false" required="true|false" /> | ||||
<description> Описание сценария </description> | ||||
<example> Пример запуска сценария </example> | ||||
</runtime> | ||||
<resource id="ResourceID"> Строка или число </resource> | ||||
<object id="ObjID" [classId="clsid:GUID"|progid="ProgID"]/> | ||||
<reference [object="ProgID"|guid="typelibGUID"][version="version"]/> | ||||
<script language="language" [src="strFileURL"]\> | ||||
<script language="language" > | ||||
<![CDATA[ | ||||
Код сценария | ||||
]]> | ||||
</script> | ||||
</job> | ||||
Другие задания | ||||
</package> |
Таким образом, из табл. 9.1 видно, что:
- элемент <package> может содержать один или несколько элементов <job> ;
- элемент <job> может содержать один или несколько элементов <runtime>, <resource>, <object>, <reference> или <script> ;
- элемент <runtime> может содержать один или несколько элементов <named> и <unnamed>, а также элементы <description> и <example>.
Обязательными для создания корректного сценария являются только элементы <job> и <script>. Сам код сценария всегда располагается внутри элемента <script>.
Опишем теперь элементы XML, использующие в сценариях WSH, более подробно.
Элементы WS-файла
В WS-файл можно вставлять комментарии независимо от разметки XML. Сделать это можно двумя способами: с помощью элемента <!-- --> или элемента <comment>. Например:
<!-- Первый комментарий -->
или
<comment> Второй комментарий </comment>
Элементы <?XML?> и <![CDATA[]]>
Эти элементы являются стандартными для разметки W3C XML 1.0. В сценариях WSH они определяют способ обработки WS-файла. Всего существует два режима обработки сценария: нестрогий (loose) и строгий (strict).
При нестрогой обработке (элемент <?XML?> отсутствует) не предполагается выполнение всех требований стандарта XML. Например, не требуется различать строчные и заглавные буквы и заключать значения атрибутов в двойные кавычки. Кроме этого, в процессе нестрогой обработки считается, что все содержимое между тегами <script> и </script> является исходным кодом сценария. Однако при таком подходе может произойти ошибочная интерпретация вложенных в сценарий зарезервированных для XML символов или слов как разметки XML. Например, имеющиеся в коде сценария знаки "меньше" (<) и "больше" (>) могут привести к прекращению разбора и выполнения сценария.
Для того чтобы задать режим строгой обработки сценария, нужно поместить элемент <?XML?> в самой первой строке сценария — никаких других символов или пустых строк перед ним быть не должно. При такой обработке WS-файла нужно четко следовать всем правилам стандарта XML. Код сценария должен быть помещен в секцию CDATA, которая начинается с символов "<![CDATA[" и заканчивается символами "]]>".
Элемент <?job?>
Элемент <?job?> задает режим отладки при выполнении WS-файла. Если значение атрибута debug равно true, то задание может быть выполнено во внешнем отладчике. Если же значение атрибута debug равно false, то отладчик для этого задания применен быть не может. По умолчанию debug имеет значение false.