Soubory systému Control Web

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é.

Organizace souborů

Sekce directories

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:

  1. test na přítomnost souboru v aktuálním (pracovním) adresáři
  2. vyhledání souboru pomocí sekce directories
  3. test na přítomnost souboru v adresáři, který obsahuje aplikační soubor (aplikační adresář)

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.

Soubory s přesměrováním

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í

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.

Přesměrování a vícemodulární aplikace

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í.

Přesměrování vcelku

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í

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í:

  1. rozhodněte se, jestli budete soubory organizovat způsobem
    1. "všechno v jednom adresáři"
    2. "soubory jednoho typu u sebe"
  2. definujte v aplikaci sekci directories. V případě, že jste zvolili variantu 1.1., nechejte sekci prázdnou. V opačném případě do ní zapište adresáře s maskami jednotlivých druhů souborů.
  3. Ujistěte se, že v adresáři s aplikací a v adresáři s konfigurací není žádný aplikační soubor s přesměrováním. Pokud takový soubor existuje, odstraňte jej (odstranění aplikačního souboru s přesměrováním je případně nabídnuto přímo ve vývojovém prostředí při odhalení kolize sekce directories a přesměrovávacího souboru).
  4. Programujete-li vícemodulární aplikaci a organizujete-li soubory podle bodu 1.2., odstraňte sekce directories ze všech modulů kromě hlavního. Organizujete-li data podle bodu 1.1., nedělejte nic, bod 2. zaručí správnou funkci sám o sobě (sekce directories je prázdná).

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.

Data systému Control Web

Soubory

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:

Adresáře

Control Web mezi všemi adresáři rozeznává několik adresářů speciálních, které používá k různým účelům:

Obecné datové soubory

DataView

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.

Bitmapové obrázky

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ů

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é.

Registrované přípony souborů

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".

Shrnutí