Вопросы по созданию приборов на С++ — Панели и приборы

В.: «что делать если грузятся два экземпляра одного прибора и дерутся между собой, вызывая ошибки в работе панели? И что делать если логика прибора не стартует, пока прибор не будет показан на экране»
О.: Отвязать логику (работы прибора/системы) от представления (от того, что в симе называется gauge). Как это сделать? Сначала экскурс в основы.
Многие начинающие прибористы воспроизводят шаблон, предложенный разработчиками сима в SDK. т.е.

GAUGE_TABLE_BEGIN()
	GAUGE_TABLE_ENTRY(&gaugehdr_attitude)
	GAUGE_TABLE_ENTRY(&gaugehdr_control_surfaces)
	GAUGE_TABLE_ENTRY(&gaugehdr_fuel)
	GAUGE_TABLE_ENTRY(&gaugehdr_fuel_selector)
	GAUGE_TABLE_ENTRY(&gaugehdr_temperature)
	GAUGE_TABLE_ENTRY(&gaugehdr_whiskey)
	GAUGE_TABLE_ENTRY(&gaugehdr_flightmap)
GAUGE_TABLE_END()

и не задумываются, что стоит за этими мудрыми словами, до тех пор пока… пока не начинают делать что-то более сложное, и не сталкиваются с проблемами наподобие вышеописанной. Собственно, данный шаблон предназначен для сокрытия программной машинерии, которая обеспечивает загрузку и отображение приборов симом. Пытаясь остатся в пределах использования этого шаблона, начинаются навороты со статическими переменными, отслеживанием многократной загрузки и тд и тп, что не способствует устойчивости модели вообще. Решение же лежит в другом, и решение это более изящно — а именно — развязывание непосредственно представления (gauges) от логики модели той или иной системы ВС. Но для этого — необходимо прекратить использовать вышеприведеннный шаблон, и начать использовать ту самую внутреннюю машинерию приборного модуля. Так что же скрывает вышеприведенный шаблон? А вот что

//GAUGE_TABLE_BEGIN()
extern GAUGEHDR gauge_header;
void FSAPI module_init(void){} //вот оно!!!
void FSAPI module_deinit(void){} //и это!!!!
BOOL WINAPI DllMain (HINSTANCE hDLL, DWORD dwReason, LPVOID lpReserved)
{
	return TRUE;
}
GAUGESIMPORT	ImportTable =						
		{													
			{ 0x0000000F, (PPANELS)NULL },					
			{ 0x00000000, NULL }								
		};													
																
																
		/* This is the module's export table. */			
		GAUGESLINKAGE Linkage =							
		{													
			0x00000013,									
			module_init,									
			module_deinit,									
			0,												
			0,												
			FS9LINK_VERSION, {
//GAUGE_TABLE_ENTRY(&gaugehdr_attitude)
				 (&gaugehdr_attitude),
//GAUGE_TABLE_END()
			0
		 }};

Итак, что мы тут видим? А видим, что шаблон скрывает определение трех функций и двух структур. Первую структуру (ImportTable) оставляем без изменений, она обеспечивает доступ к функциям сима наподобие lookup_var(). Вторая структура содержит заголовок приборного модуля, в котором указывается магическое число 0x13 (19 в десятичной системе), обозначающую для сима то, что это приборный модуль, два адреса функций, определенных ранее (module_init, module_deinit), два магических числа, нам не интересных, номер версии сима, для которой предназначен данный приборный модуль, ну а дальше идет список адресов заголовков описаний непосредственно представлений приборов (gauges), завершающееся еще одним магическим числом — 0, поскольку именно его сим ожидает увидить при загрузке списка представлений из приборного модуля, в конце означенного списка представлений.
Более детально нас интересуют именно определенные шаблоном функции. DllMain оставим в стороне, она в приборных модулях дополняется своим кодом в очень редких случаях. Более подробно интересуют две другие функции — module_init и module_deinit. Что они делают? В шаблоне по умолчанию они не делают ничего! Но! функция module_init вызывается один раз при загрузке приборного модуля, и module_deinit вызывается один раз при выгрузке модуля симом. При этом совершенно не важно, был ли отображен прибор на экране, или не был. Т.е. эти две функции выполняются всегда. Вот сюда-то нам и надо поместить инициализацию логики наших систем, загрузку всех требуемых ресурсов, а так же запуск цикла расчетов обновлений логики (в тч и асинхронное, если ваши знания позволяют это реализовать). В представлении же мы оставляем только отображение конкретных значений и прием управляющих воздействий от пользователя (мышеклики). При этом одинаковых представлений может быть любое множество, в каких угодно местах (на 2Д панели, в ВК или на внешнем компьютере). Конкретные способы реализации самой модели я сейчас рассматривать не буду.

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

Сообщение отредактировано seric76: 13 July 2012 — 05:17