Kancelářský balík MS Office 2000 a COM Add-In

Kancelářské aplikace řady Office si získaly oblibu nejenom díky poměrně jednoduchému ovládání základních funkcí...


Kancelářské aplikace řady Office si získaly oblibu nejenom díky poměrně
jednoduchému ovládání základních funkcí, ale také svou schopností přijímat
doplňky s novými užitnými vlastnostmi pocházející od jiných tvůrců, než je sám
dodavatel aplikace.
Existuje elegantní a vcelku jednoduchá možnost doplnit svůj kód k dokumentu,
tj. doplnit tzv. makro. I jedno makro dokument velice oživí. Dokument vybavený
takovýmto kódem je schopen vykonávat činnosti nad obsahem, počínaje možností
speciálního vyhledávání a konče standardními výpočty v textu a v tabulkách.
Protože tento kousek programu doplní otevřený dokument o nové užitné
vlastnosti, nehovoříme v této souvislosti o rozšiřování užitných vlastností
samotné aplikace, ale o samotném kódu makru připojenému k dokumentu.
Vytvoření makra připojeného k dokumentu v aplikaci Office není ani pro
začátečníka nikterak složité. Stačí spustit záznam makra a provést několik
zaznamenaných úkonů v tzv. kameře makra. Když poté automatem vytvořené makro
důkladně prostudujeme v editoru vývojového prostředí, jsme schopni snadno již
funkční makro doplnit. Můžeme jej tak "vylepšit", tedy optimalizovat. Kromě
možnosti vytváření makra k Office dokumentu existuje ještě další technologie
umožňující ovládat kód spojený s daným Office dokumentem. Při použití tzv.
technologie Automation, která jako speciální technologie spadá do široké rodiny
technologie COM, lze pomocí jiné, námi tvořené aplikace "vstoupit" do aplikace
Office. Tento postup se s úspěchem používá v případech, kdy námi tvořená
aplikace využije Office aplikaci ke svým účelům. Nejedná se tedy o kód
připojený k dokumentu, jak je tomu u makra, ale o připojení funkcionalit
aplikace Office k našemu programu. Pomocí této technologie můžeme např. velmi
snadno provést export dat z naší aplikace do Excelu anebo do Wordu apod. ...
Jednoduchost ovládání a tvorby maker, vzájemné propojení aplikací pomocí
technologie Automation spolu s dalšími faktory vedla k natolik rozšířenému
používání aplikací řady Office, že se ostatní podobné produkty dostaly tak
trochu do jejich stínu. Přiznejme si kdo by si dnes zvolil jako podnikatelský
záměr vytvořit nový kvalitní textový editor a dodávat jej na trh jako
konkurenci MS Wordu?
Add-In jako doplněk aplikace
Předešlý závěr by pro programátory vyzněl příliš pesimisticky, pokud by
neexistoval jeden zajímavý prostor pro tvorbu vlastních programů pro tyto
produkty. Existuje možnost zapojit se do prostoru poskytovaného trhem s těmito
produkty pomocí technologie Add-In. Právě tato technologie kombinovaná s
technologií COM nabízí do budoucna firmám velmi zajímavé možnosti jak
technologické, tak zejména obchodní.
Add-In je přímo doplněk aplikace a je k této aplikaci připojen jako externí
soubor. Na rozdíl od toho dříve popsané makro lze chápat jako "skript k
vykonání nad dokumentem" je tedy
součástí dodaného dokumentu. Oproti tomu Add-In je přímo aplikačním doplňkem,
tj. jedná se o zvláštní připojení ve formě programu k samotné aplikaci. Na
straně druhé se u Add-Inu nejedná o případ využití aplikace Office z jiné
aplikace pomocí technologie Automation. Jinak řečeno: Add-In není vnější
aplikací, která ovládá Office, jak je popsáno v předešlé kapitole při využití
Office pro reporty a výstupy do Excelu, Wordu apod. Samotný Add-In je doplňkem
k aplikaci, je k ní připojen, vzletně řečeno "srůstá s ní".
Add-In a Office 97
Verze Office 97 již podporovala tvorbu Add-In modulů podle předešlé definice,
avšak jejich použití mělo v této verzi své zvláštnosti. Následující seznam
vyjmenovává různé typy Add-Inů, které se používají v Office 97:
Word: *.dot, *.wll
Excel: *.xla, *.xll
PowerPoint: *.ppa, *.dll
Access: *.mda, *.mde
Outlook: ECEs (Exchange Client Extensions)
Všimněme si v předešlém seznamu, že každý Add-In je pro jinou Office aplikaci
reprezentován jiným typem souboru a také jiným modelem spolupráce. Skutečnost,
že každá aplikace Office (i když všechny patří do téže rodiny) vyžaduje svůj
vlastní způsob zapojení Add-Inu, je velkou brzdou používání Add-Inů v Office 97
z hlediska vývojářů i z hlediska uživatelů již hotových modulů. Pro vývojáře
tato skutečnost znamená naučit se devíti různým způsobům, jak vytvářet doplněk
k aplikaci Office. Devět různých modelů Add-Inů v Office je jak pro vývoj, tak
pro jejich užití příliš velkou nestandardizací a trh takovýmto nestandardním
použitím softwaru nepřeje.
Naopak jakákoliv standardizace výrazně aktivizuje trh. Tvůrci a uživatelé se
tak mohou soustředit na základní problém, který se má u Add-Inu řešit, jímž je
samotná užitná funkčnost Add-Inu, a nemusí plýtvat silami při řešení způsobu
spolupráce Add-Inu s aplikací. Modul Add-In je de facto externím modulem v
binárním zkompilovaném tvaru, který se "nějak" připojuje k aplikaci. Tato
aplikace je již hotová, tj. je v binárním zkompilovaném tvaru, a nikoliv ve
tvaru zdrojových kódů. Např. chceme-li vyvinout Add-In pro aplikaci Word, nikdo
nám proto nedodá Word ve tvaru zdrojových kódů, abychom jej doplnili svým kódem
externího modulu. Vždy dostaneme k dispozici již hotový, zkompilovaný balík
(resp. několik balíků) Wordu a k nim musíme náš modul připojit. Připojujeme se
tedy k hotovému binárnímu útvaru.
Na druhé straně když tento
náš doplněk-modul vytvoříme, zkompilujeme ho a dodáváme uživateli opět jako
zkompilovaný balík v binárním tvaru. Tedy podobně uživatel Add-Inu nezíská jako
výsledek našeho snažení sadu zdrojových kódů, ale nějaký binární balík. Znamená
to, že v konečném důsledku při používání Add-Inu spolupracují u uživatele dva
(nebo více) binárních zkompilovaných balíků jeden reprezentuje dodanou aplikaci
a dalšími útvary jsou Add-Iny. Základní problém
Z uvedeného je zřejmé, že základním problémem Add-Inu jako externího modulu v
binárním tvaru je otázka technologie propojení dvou binárních zkompilovaných
útvarů. Když tuto technologii propojení nějakým rozumným způsobem zavedeme,
můžeme také zavést standard pro spolupráci Add-Inů s aplikací.
Nemá smysl objevovat již objevené tato technologie propojování na binární
úrovni je již vyvinuta, odzkoušena a všeobecně známa. Obecně se jedná o
technologii binárních objektů, což v technologii Microsoft reprezentuje COM
technologie.
COM Add-In a jeho standardy
Předešlé úvahy nás zavedly až k myšlence použít technologii COM k vytvoření
standardu pro tvorbu Add-Inů, tedy doplňků k aplikacím. První dohoda tohoto
standardu je tedy zřejmá:
Add-In se bude propojovat k aplikaci pomocí COM technologie.
Dohoda je pro standard Add-Inu sice dohodou silnou, ale ještě není dostatečnou.
Představme si, že máme dva binární útvary, které jsou propojeny přes COM
technologii. Jako příklad vytváříme třeba nějaký složitý systém a v něm
existují komponenty, které navzájem spolupracují pomocí COM technologie.
Znamená to snad, že tyto komponenty jsou Add-Iny? V žádném případě. Komponenty
mohou reprezentovat různé části systému, které jsou na rovnocenné úrovni a
pouze rozvrstvují aplikaci na jednotlivé části (například komponenta účtů,
komponenta klientů apod.).
Samotné propojení pomocí COM ještě neznamená, že vztah mezi dvěma útvary je
"aplikace a její doplněk Add-In". Binární objekt Add-Inu připojený k aplikaci
musí ještě navíc splňovat analytický požadavek "býti Add-Inem". Takovýto
požadavek vyslovený pro libovolný Add-In a libovolnou aplikaci zní velmi obecně
jaké má mít vlastnosti libovolná rozšíření libovolné aplikace?
V teorii binárních objektů a speciálně v technologii COM existuje jednoduché
pravidlo: Splnění určitých analytických požadavků na binární objekt je v
konečném důsledku reprezentováno existencí některého z rozhraní objektu (v
případě COM pomocí COM interface), který realizuje dané služby požadavku. Náš
analytický požadavek na Add-In zní: "Buď extenzí aplikace." Odpovědí by měla
být existence některého z interface, který plní služby tohoto požadavku
(interface charakterizovaný jako "Buď extenzí aplikace."). Řešení, jak má tento
interface pro Add-In vypadat, nemusíme my sami hledat podařilo se jej nalézt v
druhém standardu COM Add-Inu a pouze se s ním seznámíme.
Splnění analytického požadavku, aby daný COM objekt byl Add-Inem, je dáno
existencí interface IDTExtensibility2. Tento interface a přesná dohoda o jeho
tvaru je právě ztělesněním analytického požadavku, aby daný binární COM objekt
byl Add-Inem, tj. doplňkem k aplikaci.
Jinými slovy: má-li COM objekt interface IDTExtensibility2, je Add-Inem a může
tedy plnit služby rozšíření aplikace. (O tvaru tohoto interface bude pojednáno
v další kapitole).
Zapišme druhou dohodu pro COM Add-In:
COM Add-In podporuje interface IDTExtensibility2
Avšak ani tyto dvě dohody (dohoda o propojení pomocí COM a dohoda o existenci
interface
IDTExtensibility2) ještě nejsou dostatečné pro zavedení COM Add-Inu.
Problém je v tom, že musí existovat ještě dohoda ze strany samotné aplikace,
která si tento Add-In k sobě připojuje.
Je samozřejmé, že aplikace, která k sobě připojuje COM Add-In, musí "rozumět"
interface
IDTExtensibility2, přes který spolupracuje se svou extenzí. Takovýto požadavek
vyplývá již ze samotné podstaty COM technologie na jedné straně je interface
poskytován a na straně druhé používán. Obě strany musí spolupracovat nad jedním
a tím samým rozhraním ve stejném tvaru, každý ze své strany (podobně jako ve
vztahu zásuvka-zástrčka). Aplikace se tedy musí o Add-Inu nějakým způsobem
dovědět, musí někde sdílet informaci o tom, jak a za jakých podmínek tento
Add-In připojovat. Samo přidání nebo vznik určitého Add-Inu na stroji nezaručí
jeho připojení k určité specifické aplikaci.
V technologii Microsoftu a speciálně v operačním systému Windows slouží k
takovému předávání a sdílení informací databáze Registry. V ní je nějakým
(zatím nespecifikovaným) způsobem pro aplikaci předána informace o jejích
Add-Inech a také informace o tom, co s Add-Iny učinit. Podle těchto informací
zapsaných v Registry si aplikace "naloaduje" odpovídající Add-Iny, vyžádá si od
nich interface IDTExtensibility2 a poté si rozšíření k sobě připojí. Zapišme
tedy třetí dohodu, která se týká opačného vztahu od aplikace k Add-Inu, stručně
ji vyjádříme jako:
Dohoda hostitelské aplikace pomocí zápisů v Registry
Nyní zapišme všechny tři dohody tvořící technologii COM Add-In v přehledné
podobě:
Připojení COM Add-Inu přes interface IDTExtensibility2
První dvě dohody předešlé
kapitoly jsou spolu spjaty v tom smyslu, že existence interface
IDTExtensibility2 samozřejmě předpokládá propojení aplikace a Add-Inu pomocí
COM technologie. Modul Add-Inu nabízí svůj interface IDTExtensibility2 a
aplikace přes tento modul může volat služby Add-Inu.
Takto by aplikace mohla ovládat svůj Add-In, avšak vyžaduje se, aby zpětně také
Add-In "ovlivňoval" a řídil chování samotné aplikace. V opačném případě by
Add-In nemohl plnit svou funkci rozšíření aplikace a byl by pouze přívěskem
řízeným aplikací. Proto se v objektovém modelu spolupráce mezi aplikací a jejím
Add-Inem poskytuje Add-Inu vrcholová instance objektového modelu dané aplikace.
Komponenta Add-In tuto instanci převezme (pokud možno co nejdříve po připojení
k aplikaci) a pomocí ní má zpřístupněny všechny služby a události jak této
instance, tak všech podřízených objektů v hierarchii objektového modelu
aplikace.
Kód spojený s převzetím instance aplikace může vypadat například takto:
Public objWord As Word.Application
Private Sub AddinInstance_ OnConnection (ByVal Application As Object,...)
Set objWord = Application
Debug.print objWord.Path zkušební výpis cesty pro testování...
End Sub
Aplikace jako klient komponenty COM Add-Inu používá poskytnutý interface
IDTExtensibility2 a zpětně komponenta COM Add-In má zpřístupněnu vrcholovou
instanci objektového modelu dané aplikace. V předešlém příkladovém kódu se
asociace naplnila pomocí dosazení vstupní instance Application do prázdné
instance objWord.
Dohoda zápisů v Registry
Každá aplikace, která má využívat COM Add-In podle předešlých standardů, se
musí nějakým způsobem dozvědět o existenci "svých Add-Inů". Protože COM Add-In
je COM komponentou jako každá jiná COM komponenta (může být jak EXE serverem,
tak DLL serverem, ale většinou se používá COM Add-In jako in-proc server
ActiveX DLL), bude také jako komponenta zaregistrována v databázi Registry.
Tato skutečnost odpovídá dohodám COM technologie a nesouvisí s existencí
Add-Inu jako takového, ale s jeho COM komponentní povahou. Zápisům v Registry v
tomto výkladu tedy nemusíme věnovat pozornost, protože odpovídají standardu
COMu a nejsou ničím výjimečné.
Kromě zaregistrování komponenty COM Add-Inu jako komponenty se provádějí ještě
další "speciální" zápisy do Registry, které již přímo souvisí s povahou tvořené
komponenty jako COM
Add-Inu. Do klíče v Registry na cestě:
{HKLM | HKCU}Software MicrosoftOffice<aplikace>AddinsProgID
(ProgID zde patří Add-Inu) se zapisují informace, které přímo souvisí s
vlastnostmi Add-Inu. Patří sem například informace jako FriendlyName (String),
FileName (String), LoadBehavior (DWORD bit mask určuje connection mode) atd.
Pokud používáte vhodné vývojové prostředí, které podporuje tvorbu COM Add-Inu
pomocí Wizardu, nemusíte se o tyto zápisy v Registry starat. Stačí nastavit
odpovídající hodnoty podle nabídky a k zápisu dojde automaticky při kompilaci
COM komponenty.
COM Add-Iny a Office 2000
Jak bylo řečeno, COM Add-In je COM komponentou se speciálním interfacem
IDTExtensibility2 a s dodatečným speciálním zápisem v Registry, který přináší
informace pro hostitelskou aplikaci. Pro tvorbu COM Add-Inu tedy nutně
potřebujeme takové prostředí, které je schopno námi vytvořený zdrojový kód
zkompilovat do podoby ActiveX DLL přesně podle dohod COM technologie (na rozdíl
od toho speciální zápis v Registry nemusíme z hlediska vývojáře považovat za
tak velký problém).
Pro aplikace z řady Office 2000 je důležitou ta skutečnost, že také ony
podporují možnost připojení COM Add-Inu. Znamená to, že aplikace lze rozšiřovat
standardním způsobem COM Add-In technologie, jak je popisováno v tomto článku.
Tvůrci aplikací Office 2000 však zašli ještě dále. Nejenom, že Office 2000
podporuje možnost být rozšiřován pomocí COM Add-Inu, ale navíc samo vývojové
prostředí Office 2000, tzv. Visual Basic for Application, podporuje možnost
vývoje COM Add-Inů. Produkty řady Office 2000 s vývojovým prostředím VBA jsou
pro tvorbu COM Add-Inu úplně soběstačné. Co to znamená z hlediska podpory
tvorby COM Add-Inu?
Produkty řady Office pomocí VBA poskytují plnou podporu pro editaci kódu COM
Add-Inu pomocí Wizardu, který výrazně zjednoduší tvorbu COM Add-Inu. Díky
Wizardu a jeho formulářům předáváte informace o vlastnostech COM Add-Inu. Tato
podpora není až tak podstatná.
Prostředí Office 2000 při tvorbě COM Add-Inu zkompiluje odpovídající projekt
přesně podle dohod COM technologie včetně registrace komponenty. Znamená to, že
Office 2000 využívá kompilátor COM. Tato vlastnost je již podstatná.
Office 2000 při kompilaci COM komponenty zapíše odpovídající údaje do registry
ohledně COM Add-Inu pro hostitelskou aplikaci.
Pomocí Office 2000 tedy můžete vyvinout plnohodnotnou aplikaci typu COM Add-In
a rozšiřovat tak standardním způsobem vlastnosti produktů Office 2000.
9 2104 / ijan

Popis interface IDTExtensibility2
Jak bylo řečeno, interface IDTExtensibility2 poskytuje svou existencí COM
Add-Inu vlastnosti rozšíření aplikace. Popišme si nyní tento interface
(zprávy), který může objekt pomocí tohoto interfacu přijmout a spustit své
odpovídající metody. Budeme nadále tyto zprávy (nevyplněný interface) nazývat
metodami. Je na programátorovi tvůrci COM Add-Inu, aby metody za interfacem,
tj. zprávami pro objekt, vyplnil.
MetodaPopis
OnConnectioAplikace volá tuto metodu Add-Inu
v okamžiku připojení Add-Inu
k aplikaci. V této chvíli se předává
reference na objekt vrcholové instance
objektového modelu aplikace
(Application) jako vstupní parametr
této metody.
OnDisconnectioAdd-In se odpojuje. Je čas pro
odstranění toho, co Add-In přidal.
OnStartUpCompleteBylo ukončeno bootování aplikace.
Aplikace dává možnost Add-Inu, aby se
k tomuto procesu startování připojil
a provedl svoje úkony.
OnBeginShutDowAplikace chce ukončit svou činnost. Add-In provádí ukládání apod.
Objekt Aplikace je stále ještě živoucí
a lze s ním pracovat.
OnAddinsUpdate Došlo ke změně v kolekci Add-Inů.
Je čas zjišťovat stavy jiných Add-Inů apod.
Právě metody vyplněné programátorem dávají COM objektu s tímto interfacem
vlastnosti Add-Inu.
Scénář spolupráce aplikace a jejího Add-Inu je nyní zřejmý: Při připojení
Add-Inu se okamžitě předává vrcholová instance aplikace a pomocí této instance
Add-In aplikaci ovládá (včetně řízení pomocí událostí). Naopak aplikace přes
interface volá Add-In v určitých okamžicích svého života (jak napovídají názvy
metod interface) a tím dovoluje Add-Inu na tyto události reagovat.

Jednotná technologie tvorby a použití Add-Inu
Když se podíváme na všechny modely Add-Inu ve starší verzi Office 97, zjistíme,
že základní problém, který bylo třeba z hlediska standardizace řešit, byla
otázka jednotného propojení všech Add-Inů nezávisle na aplikaci, ke které se
modul připojuje.
Každý modul z jiného typu aplikace se připojuje k aplikaci Office jiným
způsobem, jinou technologií. Tato nestandardní situace je znázorněna na obrázku
různými barvami propojení mezi jednotlivými moduly a Office aplikací.
Představme si, že by situace vypadala trochu jinak, než jak ukazuje předešlý
příliš mnohobarevný obrázek. Moduly by se připojovaly k aplikaci jednotným
způsobem. Obrázek propojení modulů k aplikaci by potom při jednotné technologii
připojení modulů mohl vypadat takto:
Všimněme si podstatného rozdílu oproti předešlému obrázku. Na první pohled se
připojení Add-Inů výrazně zjednodušilo. Všechna připojení modulů jsou
znázorněna stejnou bílou barvou, jež vyjadřuje jednotnou technologii připojení.
Řešení bylo tedy nasnadě je třeba vytvořit jednotnou technologii propojení
modulů Add-In k aplikacím.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.