Control Web a ActiveX

Historie technologie ActiveX

OLE

Středem zájmu uživatelů produktů firmy Microsoft a tím pádem i jejich vývojářů byla po dlouhou dobu práce s dokumenty. Po integraci kancelářských aplikací do balíku Office vyvstala nutnost tvorby složených dokumentů, dokumentů obsahujících mimo formátovaný text i jiné datové typy, například tabulky a grafy tabulkového kalkulátoru. Zrodila se technologie OLE — Object Linking and Embedding (český překlad by snad mohl znít Vázání a zabudovávání objektů).

Původní verze OLE, dnes označovaná jako OLE 1, byla velmi neohrabaná, pomalá a svými nároky přesahovala možnosti tehdy běžných kancelářských počítačů. Ke komunikaci mezi aplikacemi se používalo nepříliš efektivního protokolu DDE. Mezitím ve firmě Microsoft vznikla bázová technologie programových komponent, nazývaná COM — Component Object Model. COM ve své podstatě pouze definuje pojem softwarové komponenty a pojem binárního rozhraní komponenty, přístupného prostřednictvím tabulek funkcí. Taktéž definuje chování objektů jako např. jejich vznik, zánik a dynamickou detekci jejich rozhraní. Žádné další definice vlastností a chování jednotlivých komponent (i když je v názvu technologie COM použit termín objekt, z hlediska pojmů užívaných v objektově-orientovaných jazycích se o objekt nejedná, lépe by bylo hovořit o komponentě) nejsou v COM obsaženy. Na základě technologie COM byla postavena zcela nová verze OLE označovaná OLE 2. S OLE 1 má společný snad jen název.

OLE 2 umožňuje, aby na ploše jednoho kontejneru mohly existovat jednotlivé OLE dokumenty, tvořící výsledný dokument. Přičemž aplikace schopné pracovat s jednotlivými dokumenty mohou být ve zcela odlišných EXE souborech. Navíc OLE 2 umožňuje uživateli editovat vložené OLE dokumenty na ploše kontejneru, beze změny okna aplikace.

VBX

Zcela jiná vývojová skupina firmy Microsoft řešila problém, jako vyhovět řadě požadavků na rozšiřitelnost vývojového systému Visual Basic, který se mezitím stal pro svou jednoduchost a úspěšné skrývání komplexnosti vývoje aplikací pro Windows velmi polulární. Vznikl formát VBX (Visual Basic eXtension), umožňující psát vlastní komponenty, které pak bylo možno zabudovávat do formulářů aplikace Visual Basic.

Poněkud překvapivě trh s VBX komponentami velmi narostl a VBX se stalo nejživotaschopnější komponentovou technologií. Na rozdíl od objektově-orientovaných technologií VBX nekladly přílišné nároky na programátory a umožňovaly distribuovat komponenty v binární podobě, tedy bez zdrojového kódu.

Následoval logický krok překonávající řadu omezení VBX — spojení komponent systému Visual Basic a OLE dokuemntů — tzv. OLE Controls, OCX. OCX plní stejnou úlohu jako VBX, ale mají řadu výhod. Především nejsou vázány na 16bitové prostředí, ale pracují i ve 32bitových Windows. Za svou větší obecnost ale platí nárůstem složitosti.

Internet a ActiveX

Aby nějaká COM komponenta mohla být prohlášena za OCX, musí splňovat řadu podmínek, musí publikovat řadu rozhraní implementujících dosti složité chování. Tyto požadavky způsobují, že implementace OCX je složitá a DLL obsahující OCX jsou velké.

Poté, co si firma Microsoft se značným zpožděním uvědomila význam Internetu, rozhodla se rozšířit technologii OCX tak, aby jednotlivé komponenty mohly být přenášeny po síti a zabudovávány do WWW prohlížeče. V praxi to znamenalo doplnění některých vlastností, jako např. možnost postupného zavádění obsahu po pomalé síti, ale především zrušení předpisů co všechno musí OCX obsahovat. Jedinou podmínkou zůstalo, že komponenta musí být schopna pracovat v kontextu procesu svého kontejneru. Komponenta tedy není povinna vyvážet vůbec žádné rozhraní s výjimkou základního COM rozhraní IUnknown. Technologie byla marketingovým oddělením pojmenována ActiveX, složené dokumenty se nazývají Active Documents a Internet Explorer, WWW prohlížeč firmy Microsoft, začal být schopen pracovat jako kontejner pro ActiveX komponenty.

Technologie ActiveX byla do značné míry postavena jako protiváha technologie Java firmy Sun Microsystems. Ovšem Java má oproti ActiveX řadu výhod i nevýhod:

ActiveX tedy není internetovou technologií v pravém slova smyslu. HTML stránka s ActiveX komponentou totiž nepracuje na ničem jiném, než na počítači se systémem Windows a prohlížečem Internet Explorer. V prostředí Internetu se technologie ActiveX příliš nerozšířila, málokterá firma umístila na své stránky ActiveX komponenty. Mnohem většího rozšíření ale doznala v prostředí firemních intranetů s řízenou konfigurací klientů i serverů, kde lze zajistit, aby všichni klienti používali jeden operační systém a jeden WWW prohlížeč. ActiveX je tedy namísto Internetovou technologií spíše úspěšná komponentová technologie v prostředí Windows.

Control Web a ActiveX

V každém případě je ActiveX jedinou rozšířenou a univerzální komponentovou technologií v prostředí Windows. V podobě ActiveX existuje velké množství komponent, např. pro přehrávání videa, pro zobrazování PDF dokumentů, pro animace, zobrazování grafů, tabulek apod.

Systém Control Web je taktéž komponentově orientovaný. Malé jádro dokáže dynamicky rozpoznat komponenty virtuálních přístrojů a ovladačů a vybudovat z nich pracující aplikaci. Z mnoha dobrých důvodů není jako bázové technologie použito ActiveX — je tím ušetřeno velké množství paměti a času CPU spotřebovaného na režii. Přesto ale existuje most mezi komponentovou technologií systému Control Web a ActiveX v podobě virtuálního přístroje pracujícího jako univerzální ActiveX kontejner.

Virtuální přístroje systému Control Web i komponenty ActiveX mohou být programově řízeny. Toto řízení zahrnuje čtení a nastavování tzv. vlastností (properties) a vyvolávání akcí (methods). Control Web disponuje výkonným programovacím jazykem OCL (podrobně popsaným v kapitole Programování a procedury). ActiveX kontejner zajišťuje transformaci mezi vlastnostmi a metodami ActiveX komponent a OCL. Z prostředí systému Control Web tak je možné programově nastavovat vlastnosti i volat metody ActiveX komponentám.

Příklad použití ActiveX komponenty v systému Control Web

Kontejner ActiveX je komponenta systému Control Web jako řada jiných virtuálních přístrojů. Můžete jej zapsat v textovém editoru do sekce instrument zdrojového textu nebo v grafickém režimu přetáhnout z Palety přístrojů.

Základní parametr virtuálního přístroje active_x je CLSID. Zde je potřeba definovat identifikátor třídy ActiveX komponenty — CLSID (CLaSs IDentifier). CLSID je jeden z mnoha typů číselných identifikátorů používaných v OLE a ActiveX. Své číselné identifikátory mají nejen třídy objektů, ale i jejich jednotlivá rozhraní (IID) apod. Jako uživatel se ale ani s CLSID příliš nesetkáte, většinou je skryto pod obecným jménem dané komponenty.

Základní vlastností všech číselných identifikátorů je jejich globální jedinečnost — jestliže existuje identifikátor dané třídy, stejné číslo nebude použito žádnou jinou komponentou ani jinou částí, a to ani v jiném systému, v jiné zemi nebo v jiném čase. Číslo je zkrátka globálně jedinečné, všechny číselné identifikátory lze zahrnout pod jedno společné označení GUID (Globally Unique IDentifier). Vzhledem k požadavku jedinečnosti je GUID velmi velké číslo, aby nehrozilo zaplnění rozsahu. GUID obsahuje 128 bitů, existuje tedy 2128 kombinací. V desítkové soustavě to je asi 3,4×1038 kombinací, což je skutečně hodně.

Čísla GUID se podle konvence zapisují v šestnáctkové soustavě mezi složené závorky jako 32 šestnáctkových číslic. Umístění znaků '-' mezi podřetězci číslic je opět věcí konvence a neodráží žádné důležité dělení GUID:

{HHHHHHHH-HHHH-HHHH-HHHH-HHHHHHHHHHHH}

Aby byla komponenta ActiveX v prostředí Windows použitelná, musí být v systému zaregistrována, což zpravidla zajišťuje instalační program. Registrace znamená umístění několika záznamů do registrační databáze systému. Pokud potřebujete zjistit CLSID jakékoliv ActiveX komponenty, je právě registrační databáze to správné místo, kam se podívat. Záznamy o komponentě jsou vždy dostupné v registrační databázi systému pod nejvyšším klíčem "HKEY_CLASSES_ROOT".

Registry Editor

Registry Editor

Pod tímto klíčem je dostupný podklíč s běžným názvem ActiveX komponenty s jediným dalším podklíčem CLSID, obsahujícím GUID třídy komponenty.

Název ActiveX komponnety s CLSID

Název ActiveX komponnety s CLSID

Prakticky veškeré další informace jsou v databázi soustředěny pod podklíčem "HKEY_CLASSES_ROOT\CLSID". Zde je seznam všech COM komponent spolu s informacemi o jejich implementaci a možnostech. Tohoto seznamu využívají i vlastní funkce COM a OLE pro tvorbu instance komponenty.

Klíč CLSID s dalšími informacemi

Klíč CLSID s dalšími informacemi

Jako uživatelé systému Control Web sice můžete vyhledat jméno ActiveX komponenty v systémovém registru a uvést jej jako parametr name přístroje active_x, případně můžete do parametru CLSID uvést přímo řetězec CLSID, ale inspektor přístroje active_x vám nabídne veškeré dostupné ActiveX komponenty, z nichž si můžete vybrat. Podklíč CLSID totiž obsahuje veškeré COM komponenty, včetně komponent neschopných pracovat v ActiveX kontejneru.

Inspektor active_x nabízí
všechny instalované třídy

Inspektor active_x nabízí všechny instalované třídy

V záložce "properties" jsou nabízeny všechny vlastnosti ActiveX komponenty, které můžete v rámci aplikace inicializovat. Tyto vlastnosti lze měnit i za běhu prostřednictvím nativních OCL procedur přístroje active_x:

SetProperty( PropertyName : string; PropertyValue : any )
SetProperty( PropertyName : string; PropertyValue : any; index : real )
SetProperty( PropertyName : string; PropertyValue : any; index1, index2 : real )
SetProperty( PropertyName : string; PropertyValue : any;
             index1, index2, index3 : real )
GetProperty( PropertyName : string; PropertyValue : any )
GetProperty( PropertyName : string; PropertyValue : any; index : real )
GetProperty( PropertyName : string; PropertyValue : any; index1, index2 : real )
GetProperty( PropertyName : string; PropertyValue : any;
             index1, index2, index3 : real )

Čtení i zápis vlastností existuje vždy ve čtyřech variantách, pro vlastnosti bez indexu a s jedním, dvěma a třemi indexy.

Vlastnosti ActiveX komponenty

Vlastnosti ActiveX komponenty

Každý virtuální přístroj může v rámci svých procedur volat nativní procedury sám sobě nebo jiným přístrojům. Mimo vlastních nativních procedur virtuální přístroj active_x dynamicky zprostředkovává volání Automation metod ActiveX komponenty jako svých nativních procedur. Protože ale počet i signatury těchto přemapovaných nativních procedur nemohou být bez zadání vlastní komponenty známy, vytváří inspektor přístroje active_x v pomocné záložce seznam nativních procedur, které jsou k dispozici.

Automation metody mapované jako
nativní procedury

Automation metody mapované jako nativní procedury

ActiveX komponenty je možno zabudovávat do panelů aplikace Control Web a programově je řídit.

Windows Media Player jako
součást aplikace

Windows Media Player jako součást aplikace

Výpis zdrojového tvaru aplikace ukazuje řízení ActiveX komponenty prostřednictvím OCL procedur:

instrument

  window panel panel_9;
    owner = background;
    position = 19, 32, 303, 195;
    win_title = 'Media Player';
  end_panel;
  
  active_x ax;
    owner = panel_9;
    position = 95, 10, 197, 174;
    CLSID = '{22D6F312-B0F6-11D0-94AB-0080C74C7E95}';
  end_active_x;
  
  switch switch_12;
     owner = panel_9;
     position = 9, 45, 75, 31;
     mode = text_button;
     true_text = 'Stop';
     false_text = 'Stop';
  
     procedure OnOutput( Output : boolean );
     begin
      ax.Stop();
    end_procedure;
  
  end_switch;
  
  switch switch_11;
    owner = panel_9;
    position = 9, 10, 75, 31;
    mode = text_button;
    true_text = 'Play';
    false_text = 'Play';
  
    procedure OnOutput( Output : boolean );
    begin
      ax.Open('d:\winnt\clock.avi');
    end_procedure;
  
  end_switch;
  
end_instrument;