:
// humans.idl
// apeitfs.idl DOESN'T have a library statement, so import
// apeitfs.idl HE ИМЕЕТ оператора library, поэтому импортируем
import «apeitfs.idl»;
[ uuid(753A8AC9-A7FF-11d0-8C30-0080C73925BA), version(1.0), lcld(9), helpstring(«Humans that need apes»)
// «Люди, нуждающиеся в обезьянах»
]
library HumanLib {
importlib(«stdole32.tlb»);
// bring in std defs. – вносим стандартные определения
// Dogs.idl DOES have a library definition, so importlib
// its corresponding type library
// Dogs.idl ИМЕЕТ определение библиотеки, поэтому
// импортируем библиотеку соответствующего типа
importlib(«dogs.tlb»);
[uuid(753A8AD1-A7FF-11d0-8C30-0080C73925BA)]
coclass DogApe {
interface IDog;
interface IApe;
} }
В простых проектах часто используется один IDL-файл, в котором определяются как интерфейсы, так и классы, экспортируемые из проекта. Для простых интерфейсов это имеет смысл, так как генерируемая библиотека типов будет содержать взаимно однозначные образы исходных определений IDL, что позволит пользователям этой библиотеки применять importlib без потери информации. К сожалению, в случае сложных интерфейсов многие из исходных IDL-измов (IDL-ism) теряются в результирующей библиотеке типов, и тогда importlib не будет работать так, как хотелось бы. Грядущая версия компилятора MIDL, быть может, будет способна генерировать библиотеки типов, которые будут содержать все из исходного IDL.
Часто случается, что разработчики классов желают развернуть новые версии уже существующих классов, чтобы исправить дефекты или расширить функциональные возможности. Полезно придать этим новым реализациям новые идентификаторы класса CLSID , чтобы клиенты могли четко различать, какая версия им нужна. В качестве примера посмотрим, что происходит, когда развертывается новая версия класса. Если для идентификации нового класса используется новый CLSID, (например, CLSID_Chimp2), то клиентам, определенно желающим использовать новую версию, следует использовать новый CLSID во время активации: // new client – новый клиент
IАре *рАре = 0; hr = CoCreateInstance(CLSID_Chimp2, 0, CLSCTX_ALL, IID_Ape, (void**)&pApe);
Использование второго CLSID гарантирует, что клиенты не получат случайно старую версию класса Chimp . В то же время старые клиенты делают запросы на активацию с применением старого CLSID:
// old client – старый клиент
IАре *рАре = 0;
hr = CoCreateInstance(CLSID_Chimp, 0, CLSCTX_ALL, IID_Ape, (void**)&pApe);
