Oktell Support в 10:59, 1 апреля 2014

2014-04-01T10:59:00Z

Oktell Support в 10:58, 1 апреля 2014

2014-04-01T10:58:51Z

Oktell Support в 15:02, 31 марта 2014

2014-03-31T15:02:22Z

Oktell Support в 15:01, 31 марта 2014

2014-03-31T15:01:39Z

Oktell Support в 15:01, 31 марта 2014

2014-03-31T15:01:06Z

Oktell Support: Новая страница: «Наверх Для разработки plugin-программы понадобится Visual Studio. Реком...»

2014-03-31T15:00:13Z

Новая страница: «Наверх Для разработки plugin-программы понадобится Visual Studio. Реком...»

Новая страница

[[Встраиваемые_plugin-модули|Наверх]]

Для разработки plugin-программы понадобится Visual Studio. Рекомендуется производить билд сборок под версию фреймворка, идентичную используемой Oktell. В настоящее время версия 2.5 использует по умолчанию Framework 1.1 (не забывайте ставить SP1). Эта версия уже установлена с клиентским приложением Oktell и всегда доступна на клиентских станциях.

При сборке в других версиях необходимо гарантировать наличие соответствующего Framework на всех клиентских компьютерах. Также стоит помнить, что исполняемая среда CLR дает возможность подгружать только те сборки, которые скомпилированы в среде текущей или более младшей версии. Таким образом, например при использовании plugin-программ, созданных и скомпилированных в 2.0,необходимо переключить комплекс на использование Framework 2.0 (в конфигурационном файле сервера и всех клиентских станций ключ supportedRuntime), в противном случае эта plugin-программа не будет загружена.

Процесс разработки можно разделить на несколько этапов:

#Установить Visual Studio.
#Установить Framework.
#Создать решение (solution).
#Создать проект (project) типа «Windows Control Library» (или «Windows Class Library»).
#Создать в проекте класс управления.
#Объявить в теле проекта в доступном для класса управления месте делегат для события OnQuery.
#В теле класса создать заглушки для всех интерфейсных методов и событие OnQuery. Приложением Oktell будет создан один экземпляр класса, соответственно методы должны быть нестатическими (у объекта, а не у класса).
#Обеспечить возврат обще-модульными методами идентификатора, названия и версии.

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

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

Для этого соответственно рекомендуется создать в текущем solution дополнительный тестовый проект типа «Windows Application», который будет обеспечивать вызов и отображение соответствующих форм и запуск соответствующих алгоритмов. Связать его статически с основным проектом и настроить его на работу с разрабатываемыми формами (это можно сделать как непосредственно, так и опосредованно через класс управления).

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

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

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

Для удобства работы с XML разработчикам предоставляется код пространства имен (namespace), в котором объявлены классы, преобразующие описанную в разделе «[[Формат параметров и выходных значений|формат параметров]]» строку c XML-содержимым в объектную модель и наоборот. Формат работы с этими объектами будет рассмотрен отдельно в разделе «[[Объектная модель XML-парсера|Объектная модель XML-парсера]]».

Разработчику следует знать: plugin-программа (главная сборка и ее окружение) будет загружена приложением Oktell в отдельный домен. Это дает определенные преимущества, но также накладывает некоторые ограничения. Это необходимо принимать во внимание там, где это играет роль. При регистрации программы администратор Oktell может установить загрузку в домен приложения, а также выбрать момент загрузки - на старте или на первом обращении. В любом случае plugin-программа, если она еще не загружена, подгружается в отдельный домен для доступа к невизуальным методам при регистрации и настройке сценариев и/или меню.

Все вызовы plugin-программы стоят в блоках try..catch, и возникающие исключения логируются в журнал Plugin. Вызовы происходят в главном потоке приложения. Это также необходимо принимать во внимание. В частности, создаваемые контролы получают очередь обработки в основном потоке приложения. Таким образом, все необработанные исключения, получаемые в интерфейсе plugin-программы, будут влечь исключения главного потока и выбивание приложения Oktell.

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

Для программ, подгружаемых в домен приложения, создание контролов ОБЯЗАТЕЛЬНО должно производиться в потоке приложения, так как в противном случае их размещение в окнах приложения Oktell станет невозможным. Это не касается диалоговых форм, имеющих собственное окно. Ранее это не имело значения и для контролов, так как механизм их размещения в клиентском приложении Oktell совпадал с используемым для работы отдельного домена.

Уточнить, куда именно загружена plugin-программа, можно, например, сравнив пути '''Application.StartupPath''' и '''AppDomain.CurrentDomain.ApplicationBase'''. Для отдельных доменов базовым выставляется путь к папке, в которой лежит основная сборка.

Plugin-программа, загружаемая в отдельный домен, может иметь свой конфигурационный файл. При создании домена путь к нему определяется как к главной сборке с дополнительным расширением «.config».

Очень важно иметь обработку исключений (блок try..catch) в конструкторе управляющего объекта, в противном случае при попытке регистрации приложением Oktell будет выдаваться отказ по причине несоответствия интерфейса. Например, исключения может возникнуть при создании в конструкторе управляющего объекта других объектов, описанных в других сборках. При изменении классов, дополнении/изменении свойств, естественно могут возникнуть исключения. Рекомендуется их обрабатывать отдельно и уведомлять пользователя генерацией OnQuery.notify. Однако, подписка на OnQuery происходит после выяснения интерфейса. Поэтому возникающие в конструкторе исключения передавать через OnQuery нужно отложенным методом (например на первом вызове любого сервисного метода).

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

Взамен, инициализацию визуальных форм рекомендуется проводить непосредственно при их вызове, невизуальные действия проводить при первом обращении на отображение диалоговой формы (или при вызове [[Сервисное взаимодействие#Объектная модель XML-парсера|DoQuery.PluginLoaded]]).

В случае возникновения спорных моментов и проблем рекомендуется пользоваться стандартным лог-журналом (осуществлять в него запись в стандартном для Oktell виде через событие OnQuery).

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

В конфигурационном файле клиентского приложения Oktell в отладочных целях можно выставлять значение ключа <span style="color:blue">Debug_PingErrorRestart</span> в <span style="color:blue">0</span>. Это исключит перезагрузку клиентского приложения по отсутствию или таймауту PING с сервером, что происходит в случае приостановки всех потоков во время отладки.

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

← Предыдущая		Версия 10:59, 1 апреля 2014
Строка 71:		Строка 71:

	При необходимости разработчику доступен стандартный механизм отладки, для этого необходимо подключиться к процессу клиентского приложения Oktell, предварительно зарегистрировав в нем debug-сборку plugin-программы с дополнительным отладочным файлом.		При необходимости разработчику доступен стандартный механизм отладки, для этого необходимо подключиться к процессу клиентского приложения Oktell, предварительно зарегистрировав в нем debug-сборку plugin-программы с дополнительным отладочным файлом.
		+
		+
		+	{\|cellpadding="10" cellspacing="0" border="0"
		+	\| [[Встраиваемые_plugin-модули\|Наверх]]
		+	\| [[Сервисное взаимодействие\|Сервисное взаимодействие<<<]]
		+	\| [[Рекомендации разработчику]]
		+	\| [[Объектная модель XML-парсера\|>>>Объектная модель XML-парсера]]
		+	\|-
		+	\|}

← Предыдущая		Версия 10:58, 1 апреля 2014
Строка 1:		Строка 1:
−	[[Встраиваемые_plugin-модули\|Наверх]]	+	{\|cellpadding="10" cellspacing="0" border="0"
		+	\| [[Встраиваемые_plugin-модули\|Наверх]]
		+	\| [[Сервисное взаимодействие\|Сервисное взаимодействие<<<]]
		+	\| [[Рекомендации разработчику]]
		+	\| [[Объектная модель XML-парсера\|>>>Объектная модель XML-парсера]]
		+	\|-
		+	\|}

	Для разработки plugin-программы понадобится Visual Studio. Рекомендуется производить билд сборок под версию фреймворка, идентичную используемой Oktell. В настоящее время версия 2.5 использует по умолчанию Framework 1.1 (не забывайте ставить SP1). Эта версия уже установлена с клиентским приложением Oktell и всегда доступна на клиентских станциях.		Для разработки plugin-программы понадобится Visual Studio. Рекомендуется производить билд сборок под версию фреймворка, идентичную используемой Oktell. В настоящее время версия 2.5 использует по умолчанию Framework 1.1 (не забывайте ставить SP1). Эта версия уже установлена с клиентским приложением Oktell и всегда доступна на клиентских станциях.

← Предыдущая		Версия 15:02, 31 марта 2014
Строка 54:		Строка 54:
	Рекомендуется не производить множественных инициализаций в конструкторе управляющего объекта. Не всегда его создание сопровождается работой plugin-программы в полную силу. В частности, при действиях в администраторских модулях (задание свойств plugin-формы при редактировании диалоговых сценариев, просмотр списка подключенных plugin-программ) происходит невизуальное взаимодействие клиентского приложения с plugin-программой; создание управляющего объекта производится с целью проверки интерфейса, а также запроса идентификатора и перечня заявленных в нем форм. При этом plugin-программа всегда загружается в отдельный домен с последующей выгрузкой. Разумеется, не имеет большого смысла создавать сетевые подключения, инициализировать визуальные формы и другие объекты, используемые при реальной работе.		Рекомендуется не производить множественных инициализаций в конструкторе управляющего объекта. Не всегда его создание сопровождается работой plugin-программы в полную силу. В частности, при действиях в администраторских модулях (задание свойств plugin-формы при редактировании диалоговых сценариев, просмотр списка подключенных plugin-программ) происходит невизуальное взаимодействие клиентского приложения с plugin-программой; создание управляющего объекта производится с целью проверки интерфейса, а также запроса идентификатора и перечня заявленных в нем форм. При этом plugin-программа всегда загружается в отдельный домен с последующей выгрузкой. Разумеется, не имеет большого смысла создавать сетевые подключения, инициализировать визуальные формы и другие объекты, используемые при реальной работе.

−	Взамен, инициализацию визуальных форм рекомендуется проводить непосредственно при их вызове, невизуальные действия проводить при первом обращении на отображение диалоговой формы (или при вызове [[Сервисное взаимодействие#~~Объектная модель XML-парсера~~\|DoQuery.pluginloaded]]).	+	Взамен, инициализацию визуальных форм рекомендуется проводить непосредственно при их вызове, невизуальные действия проводить при первом обращении на отображение диалоговой формы (или при вызове [[Сервисное взаимодействие#pluginloaded\|DoQuery.pluginloaded]]).

← Предыдущая		Версия 15:01, 31 марта 2014
Строка 54:		Строка 54:
	Рекомендуется не производить множественных инициализаций в конструкторе управляющего объекта. Не всегда его создание сопровождается работой plugin-программы в полную силу. В частности, при действиях в администраторских модулях (задание свойств plugin-формы при редактировании диалоговых сценариев, просмотр списка подключенных plugin-программ) происходит невизуальное взаимодействие клиентского приложения с plugin-программой; создание управляющего объекта производится с целью проверки интерфейса, а также запроса идентификатора и перечня заявленных в нем форм. При этом plugin-программа всегда загружается в отдельный домен с последующей выгрузкой. Разумеется, не имеет большого смысла создавать сетевые подключения, инициализировать визуальные формы и другие объекты, используемые при реальной работе.		Рекомендуется не производить множественных инициализаций в конструкторе управляющего объекта. Не всегда его создание сопровождается работой plugin-программы в полную силу. В частности, при действиях в администраторских модулях (задание свойств plugin-формы при редактировании диалоговых сценариев, просмотр списка подключенных plugin-программ) происходит невизуальное взаимодействие клиентского приложения с plugin-программой; создание управляющего объекта производится с целью проверки интерфейса, а также запроса идентификатора и перечня заявленных в нем форм. При этом plugin-программа всегда загружается в отдельный домен с последующей выгрузкой. Разумеется, не имеет большого смысла создавать сетевые подключения, инициализировать визуальные формы и другие объекты, используемые при реальной работе.

−	Взамен, инициализацию визуальных форм рекомендуется проводить непосредственно при их вызове, невизуальные действия проводить при первом обращении на отображение диалоговой формы (или при вызове [[Сервисное взаимодействие#Объектная модель XML-парсера\|DoQuery.~~PluginLoaded~~]]).	+	Взамен, инициализацию визуальных форм рекомендуется проводить непосредственно при их вызове, невизуальные действия проводить при первом обращении на отображение диалоговой формы (или при вызове [[Сервисное взаимодействие#Объектная модель XML-парсера\|DoQuery.pluginloaded]]).

← Предыдущая		Версия 15:01, 31 марта 2014
Строка 31:		Строка 31:


−	Для удобства работы с XML разработчикам предоставляется код пространства имен (namespace), в котором объявлены классы, преобразующие описанную в разделе «[[Формат параметров и выходных значений\|~~формат~~ параметров]]» строку c XML-содержимым в объектную модель и наоборот. Формат работы с этими объектами будет рассмотрен отдельно в разделе «[[Объектная модель XML-парсера\|Объектная модель XML-парсера]]».	+	Для удобства работы с XML разработчикам предоставляется код пространства имен (namespace), в котором объявлены классы, преобразующие описанную в разделе [[Формат параметров и выходных значений\|«Формат параметров и выходных значений»]] строку c XML-содержимым в объектную модель и наоборот. Формат работы с этими объектами будет рассмотрен отдельно в разделе «[[Объектная модель XML-парсера\|Объектная модель XML-парсера]]».

Рекомендации разработчику - История изменений

Oktell Support в 10:59, 1 апреля 2014

Oktell Support в 10:58, 1 апреля 2014

Oktell Support в 15:02, 31 марта 2014

Oktell Support в 15:01, 31 марта 2014

Oktell Support в 15:01, 31 марта 2014

Oktell Support: Новая страница: «Наверх Для разработки plugin-программы понадобится Visual Studio. Реком...»