Aplikace systému Control Web (stejně jako Control Web sám) používá při svém běhu celou řadu různých pomocných souborů. Soubory obyčejně obsahují data, kresby nebo konfigurace, případně výsledky činnosti — databáze, protokoly anebo provozní deníky. Celkové množství souborů, které aplikace potřebuje ke svému běhu, proto může být dosti velké.
Aplikace se musí v množství souborů nějak orientovat, musí být schopna všechny své soubory najít — jinak by se nemohla rozběhnout, a případně také musí vědět, kde může vytvářet soubory s výsledky. Control Web proto v aplikaci definuje samostatnou sekci directories, která umístění všech souborů dokáže popsat. Veškeré aplikační objekty (přístroje) se touto sekcí řídí — navíc aplikace sama může s využitím systémových nativních metod zjistit, kde se který soubor nachází.
Sekce directories má velmi jednoduchou syntaxi:
directories '*.par' = 'd:\work\cw'; '*.jpg' = '\\D_S\data\img', 'c:\Moje obrázky'; 'a*.cbk' = 'd:\data', 'd:\backup_data'; 'b*.cbk' = 'd:\backup_data'; end_directories;
Každý řádek obsahuje jedno pravidlo, které definuje jednak masku pro jméno souboru a jednak několik adresářů, ve kterých mohou soubory vyhovující dané masce existovat. Maska může obsahovat dva zástupné znaky — ? pro jeden jakýkoli znak a * pro libovolný počet jakýchkoli znaků. Většinou maska pro jméno souboru definuje pouze příponu a ponechává jméno souboru neomezené (například maska '*.dbf'). Podobně jako v uvedené ukázce je však možné i soubory s jednou příponou blíže rozlišit a přiřadit jim různé adresáře.
Mechanizmus vyhledávání souborů zapsaných v sekci directories je také jednoduchý. Aplikace definovaný seznam pravidel postupně prochází a současně zjišťuje, jestli jméno hledaného souboru vyhovuje masce pravidla. Pokud ano, prochází se dále seznam adresářů a ověřuje se, jestli soubor daného jména v adresáři existuje. Nakonec tedy bude vždy použit soubor, který systém nalezne jako první. Při vytváření souborů (to je například případ všech archívů a záložních souborů) systém při nalezení odpovídající masky použije vždy první definovaný adresář.
Sekce directories není prvním místem, kde aplikace soubor vyhledává. Kompletní mechanizmus hledání souborů totiž pracuje ve třech krocích:
Uvedený mechanizmus je zcela základní, a je velmi vhodné mít jej stále na paměti — například: jednoduše může vzniknout situace, kdy (například při přesunu aplikace do jiného prostředí) systém vybere soubor správného jména z jiného adresáře (z adresáře, který mechanizmus vyhledávání používá dříve). Tehdy nemusí některé objekty (například ovladače) správně pracovat, neboť se "omylem" použije jiný soubor. Pro lepší vysvětlení ještě jeden příklad: soubor 'simatic.dmf' uložený v aplikačním adreáři nebude použit, pokud aplikace dříve (pomocí sekce directories) stejný soubor 'simatic.dmf' objeví v adresáři 'Control Web\dmf'.
Z mechanizmu také vyplývá, že zaručená cesta k úspěšnému nalezení všech souborů je shromáždění těchto souborů v jednom adresáři s celou aplikací — systém tehdy nalezne soubor vždy podle bodu 3 vyhledávacího mechanizmu.
Není (bohužel) možné jednoznačně říci, který způsob uspořádání souborů přednostně využívat — jestli variantu "soubory stejného typu na jednom místě" (= používání sekce directories) nebo variantu "všechny soubory jedné aplikace na jednom místě" (= vypuštění sekce directories). Je možné, že během vývoje může být užitečnější varianta první a pro ostrý provoz varianta druhá. Pro shromáždění souborů použitých v aplikaci je určen "Průvodce generováním aplikace", který je dostupný ve vývojovém prostředí a který je popsán v kapitole Control Web Runtime.
Body 2. a 3. mechanizmu hledání souborů pracují jen je-li sekce directories v aplikaci definována (to je doporučený stav). V opačném případě se systém Control Web chová podle pravidel nižších verzí a používá soubory s přesměrováním.
Soubory s přesměrováním jsou předchůdci sekce directories a slouží stejnému cíli — informují aplikaci o možném umístění datových souborů. Obsah souboru s přesměrováním je velmi podobný sekci directories, rozdíl spočívá víceméně pouze ve vypuštění apostrofů kolem řetězců s maskami a cestami. Existují dva druhy souborů s přesměrováním — systémový (ten používá Control Web interně) a aplikační. Systémový soubor ('cw.red') je uložen v adresáři s konfiguračními soubory (po instalaci to je adresář, který obsahuje soubor 'cw.exe') a aplikace jej použije v případě, když nenajde ani sekci directories ani aplikační soubor s přesměrováním.
Pokud systém nalezne před spuštěním nebo překladem v adresáři s aplikací soubor stejného jména s příponou '*.red' (například u aplikace se jménem 'App_01_Test.cw' bude systém hledat soubor 'App_01_Test.red'), předřadí ho před soubor systémový a použije jej. Takto nalezený soubor s přesměrováním je aplikační soubor s přesměrováním.
Aplikace soubory vyhledává podle systémového i aplikačního souboru s přesměrováním shodně — možný definovaný neúplný adresář (například '..\dmf') je vždy vztažen k adresáři s aplikací (pravidlo vypadá samozřejmě, ale druhá možná nepoužitá varianta by vztahovala neúplné adresáře k aktuálnímu pracovnímu adresáři, a to by také mohlo být docela použitelné).
Při přenosu aplikací z nižších verzí systému Control Web může nastat situace, kdy systém nalezne nějaký aplikační soubor s přesměrováním a současně již bude ve zdrojovém textu definována sekce directories. Nastane logická kolize, kterou systém vyřeší jednoduše — dá přednost "košili místo kabátu" a použije sekci directories. O vzniklé situaci systém informuje dialogovým oknem:
Kolize přesměrování
Zobrazení tohoto okna je dosti důležité — systém ví, že si zvolil sekci directories, uživatel to však vědět nemusí (přesněji, asi to také ví, ale ne vždy si to ve shonu při vývoji aplikace nutně uvědomí). Tento nesoulad myšleného a skutečného by mohl způsobit nemilá překvapení — mohly by se použít jiné soubory, než tvůrce zamýšlel. Právě proto, aby se takovým nemilým překvapením předešlo, otevírá systém uvedené dialogové okno.
Aplikace může sestávat z několika modulů. Každý modul může definovat svou vlastní sekci directories a může tudíž své soubory hledat na různých místech. Když se to potom dá dohromady, může vzniknout docela znamenitý chaos.
Soubory ve vícemodulárních aplikacích proto Control Web dokáže spravovat rozumněji. V případě, že nějaký modul (kromě hlavního) nemá ani sekci directories a ani u něj neexistuje aplikační soubor s přesměrováním, použije se přesměrování hlavního modulu. Jinak řečeno, modul automaticky převezme přesměrování z hlavního modulu v případě, kdy nemá žádné své přesměrování.
Nyní se pokusím popsané skutečnosti přehledně shrnout do jednoho (velkého) schématu znázorňujícího všechny varianty výběru různého přesměrování:
Výběr přesměrování
Povšimněte si, že varianta "ne" u existence systémového souboru s přesměrováním znamená, že přesměrování nebude definováno a že tudíž budou nalezeny jen soubory umístěné v aktuálním pracovním adresáři (nalezené podle pravidla 1 mechanizmu přesměrování).
Co lze říci o přesměrování nakonec? Přesměrování je velmi mocný nástroj, který občas (při povrchním pohledu) může (bohužel) vypadat jako zbytečně komplikovaný a matoucí. Situace je navíc ještě složitější kvůli kompatibilitě (kvůli souborům s přesměrováním). Následující doporučená pravidla by měla většině případů zaručit bezproblémové chování přesměrování:
Systém Control Web standardně při vzniku nové aplikace definuje sekci directories a ponechává ji prázdnou — podle předchozích pokynů tedy postupuje podle bodu 1.1. Pokud vám takové nastavení vyhovuje, stačí už jen potřebné datové soubory ukládat do jednoho adresáře k aplikaci.
Aplikace může informace o úplných cestách k souborům zjistit pomocí systémových nativních procedur GetREDFullPath a GetREDCreatePath. Tyto procedury plně respektují všechna výše popsananá pravidla pro výběr adresáře v němž bude soubor hledán, případně vytvářen.
Systém Control Web (a jeho aplikace) používá soubory několika vlastních formátů. Přehled těchto formátů, spolu s jejich popisem, nabízí seznam:
Pokud vývojové prostředí načte nějaký '*.cp' soubor, pracuje s ním jako s vlastní aplikací. Jakmile však aplikaci překlopíte do grafického režimu, bude nutně zdrojový text později znova vygenerován (buď při uložení, nebo při překlopení do textu) a nabude formy zápisu platné pro systém Control Web. To znamená, že nově vygenerovaný soubor '*.cp' nebude zpětně použitelný v systému Control Panel. Změna formátu z '*.cp' na '*.cw' proběhne automaticky, nicméně před uložením upraveného (nově vygenerovaného) souboru '*.cp' systém upozorní na možné souvislosti následujícím oknem:
Změna formátu aplikace
Soubor '*.cw' (i '*.cp') je textový a můžete jej proto upravovat v libovolném textovém editoru. Samozřejmě, pouze vestavěný editor vývojového prostředí systému Control Web podporuje různá rozšíření, jako je barvení textu, podpora inkrementálního překladu a podobně.
Soubor '*.cwx' je možné vytvořit ve vývojovém prostředí buď pomocí menu "Soubor/Generovat CWX soubor..." anebo pomocí "Průvodce generováním aplikace" (ten je popsán v kapitole Control Web Runtime. Druhý způsob tvorby je sofistikovanější a dokáže více věcí (kopírovat i datové soubory aplikace), nicméně pro rychlé vyrobení souboru '*.cwx' bohatě postačí i metoda první.
begin 1 string output 2 longcard input 100 - 199 real bidirectional 200 - 299 real input 300 - 399 real output 500 - 509 boolean bidirectional 1000 - 1099 longint output end.
Každý řádek definuje nejprve číslo kanálu ovladače (případně interval čísel), dále pak datový typ kanálu a nakonec směr kanálu. Pokud kanál definovaný v aplikaci neodpovídá údajům v '*.dmf' hlásí Control Web chybu překladu.
Zápis souboru není nijak standardizován — pouze novější ovladače dělí soubor na sekce a parametry zapisují podle konvence inicializačních ('*.ini') souborů. Popis parametrických souborů je vždy součástí dokumentace ovladače, navíc, každý ovladač je dodáván s několika ukázkami parametrických souborů připravených pro typická použití.
[název sekce ...] parametr = hodnota ... [jiná sekce ...] parametr = hodnota ...
Sekce logicky oddělují různé skupiny parametrů, které jsou způsobem klíč = hodnota. Ovladače většinou zapisují své parametrické soubory právě v tomto formátu. Reprezentantem formátu je soubor 'cw.ini', který obsahuje některá systémová nastavení a neměl by být upravován.
Popsanému formátu konfiguračních souborů v systému Control Web neodpovídají následující soubory:
Všechny čtyři popsané soubory jsou textové, a opět se nedoporučuje jejich úprava.
Pro snazší možnost údržby doporučujeme používat soubory '*.ico' ve formátu systému Control Web, neboť takové ikony jsou plně pod kontrolou systému Control Web (a tím i pod kontrolou vaší).
Control Web mezi všemi adresáři rozeznává několik adresářů speciálních, které používá k různým účelům:
cw /p=c:\localdata\controlweb
Control Web spuštěný s tímto parametrem bude načítat konfiguraci z adresáře 'c:\localdata\controlweb'. Za konfigurační soubory Control Web považuje všechny '*.ini' soubory, 'cw.red' a '*.log' soubory se zprávami systému. Pokud některý ze souborů není nalezen, použije Control Web soubor stejného jména z adresáře s 'cw.exe'.
Control Web pracuje s nejrůznějšími typy datových souborů. Pro každou skupinu dat (obrázky, texty) vnitřně definuje speciální objekt — DataView, který jednotným způsobem systému a aplikaci zprostředkuje všechny požadované operace. Každé DataView se proto umí vytisknout, přizpůsobit okolnímu prostředí a samozřejmě zobrazit.
V aplikaci systému Control Web se s DataView setkáte především v přístroji panel, který DataView plně podporuje jako své možné pozadí. Do přístroje panel proto můžete zařadit datový soubor, kterému rozumí jedno z existujících DataView:
Nejčastěji používanými podklady panelů jsou bitmapy — obrázky se schématy technologií či podniků. Protože je tato skupina datových souborů zdaleka největší, bude další popis věnován právě jim.
Soubory s obrazovými daty bývají poměrně malé, neboť většina formátů data silně komprimuje (například '*.gif' nebo '*.jpg'). Načtení a zobrazení obrázku vyžaduje rozbalení těchto dat, což způsobí značné "nafouknutí" obsazeného paměťového prostoru. Spotřeba paměti je (mimo vlastní rozměry obrázku) hlavně určena barevnou hloubkou grafického ovladače. Následující tabulka ukazuje, kolik místa v paměti obsadí obrázek o velikosti 1 024×768 bodů (běžné rozlišení displeje):
Spotřeba paměti obrázků
Uvedené hodnoty platí pro jednu bitmapu. Uvážíme-li, že obrázek musí být nejprve rozbalen ze souboru do paměti, posléze případně vyditrován (ditrování přizpůsobuje barvy obrázku barvám použitým na displeji) a zmenšen (nebo zvětšen) do podoby, která se uchová pro zobrazování, dojdeme k maximální obsazené paměti rovné (přibližně) čtyřnásobku hodnot uvedených v tabulce! Ditrování a úprava velikosti jsou operace dočasné, takže použitá paměť je po jejich ukončení uvolněna, ale i tak zůstanou v paměti dvě podoby každého obrázku — obrázek původní a obrázek zobrazitelný. Tedy dvě kopie. Deset panelů s obrázkem o velikosti 1 024×768 bodů v barevnosti 16 M barev použitých na displeji s 256 barvami obsadí celkem:
Tato paměť musí být samozřejmě k dispozici, zůstává obsazená a tudíž nepoužitelná pro jiná data (například výpočty, přístroje a datové elementy). S obrázky je proto třeba zacházet rozumně. Jednak je vhodné vyrábět obrázky v co možná nejnižší barevnosti, a jednak je vhodné s nimi při běhu aplikace pracovat efektivními metodami. Například je možné pozadí panelu z disku nahrát až v okamžiku jeho zobrazení (například v metodě OnShow, nebo definicí parametru load_on_show) — vybavíte-li touto vlastností všechny panely, bude v paměti vždy přítomno jen nezbytně nutné množství obrázků.
Bohužel, obecně se velikost obrázků příliš zmenšovat nedá, takže graficky náročné aplikace budou mít vždy větší spotřebu paměti. Potom je na vás, abyste na tuto skutečnost patřičně reagovali a pro běh takové aplikace použili počítač dostatečně dimenzovaný.
Jiná možnost, jak zmenšit paměťovou náročnost obrázků je použití vektorové kresby — kresby vyjádřené pomocí grafických elementů, jako jsou čáry, mnohoúhelníky nebo elipsy. Vektorová kresba je mnohem menší než bitmapová a také se většinou lépe udržuje. Navíc nebývají problémy s jejím zmenšováním nebo zvětšováním. V systému Control Web můžete použít vektorový editor InDraw pracující s formátem '*.idr'. Výsledné vektorové kresby je možné umístit na pozadí panelu stejně jednoduše jako obrázky bitmapové.
Systémy Windows umožňují spojit příponu souboru s aplikací. Spojení usnadňuje spouštění aplikace — definicí spojení vytvoříte vazbu mezi formátem souboru a aplikací operačního systému, která danému formátu rozumí. Je-li spojení formátu a aplikace definováno, můžete registrované soubory spouštět přímo — například klik na textový soubor automaticky spustí textový editor a soubor do něj zavede.
Control Web registruje dvě přípony — 'cw' a 'cwx'. Vývojová verze registruje příponu 'cw' vždy a příponu 'cwx' jen není-li obsazena (například systémem Control Web Runtime); naopak Control Web Runtime registruje vždy příponu 'cwx' a příponu 'cw' jen není-li již zaregistrovaná.
Registraci přípon operační systém signalizuje malou ikonou umístěnou před jménem souboru — ikona je viditelná například v dialogových oknech "Otevřít" a "Uložit".