RAD - Rapid Application Development - Builder.cz - Informacni server o programovani

Navigace:  » Úvodní stránka  » Rubriky  » Delphi  

16. listopadu 2001, 00.00 | Víte čeho se vyvarovat při tvorbě programů, aby váš rapidní vývoj nezískal nechtěně nějakou tu vadu na kráse? Že vám vše funguje a hezky vypadá? A již jste svůj program zkoušeli i v jiném rozlišení?!

Co vlastně znamená zkratka RAD? "Rychlý vývoj aplikace." Otázkou je zda vývoj aplikací přes toto rozhraní, je opravdu tak rapidní (rychlý), jak si většina z Vás připouští či jak činí. 

V čem spočívá výhoda RAD? Především v tom, že můžete pomocí myši naházet na formulář dané komponenty a nějakým způsobem je uspořádat, což vlastně znamená, že nějaký robot za Vás napíše skript, který vytvoří všechny komponenty v daném hierarchickém modelu, jak jste si rozvrhli na ploše, a naplní je hodnotami. Pro Vás tedy odpadá velice nudná a zdlouhavá práce psaní create(self); parent:= …; …name:= …. Toto je opravdu nesporný přínos tohoto přístupu, který opravdu může učinit vývoj aplikace rychlejším.  

Toto je asi místo, kde množství čtenářů přestává číst. Někteří další znají, že lze zamykat polohu komponent, a tak mít zajištěno, že si danou komponentu při vývoji omylem neposunu.

Špatné na tom je, že by tento text už nečetli ani někteří profesionální programátoři.  

Ale jaké jsou nevýhody tohoto přístupu? Většina takových programátorů logicky, ale nesprávně odvozuje, že tento přístup řeší vše! Především to, že ve svých aplikacích nepoužívají procedure onResize, onConstrainResize¹ (Delphi6) a onPaint. Říkají si totiž, proč definovat tyto procedury, když po vytvoření daného formuláře, mám přeci na ploše zobrazeny komponenty, tak jak je vidím před sebou, a ty jsou dobře. Problém je v tom, že takto vyvíjíte aplikace v nějakém standardu :-( tzn. rozlišení, velikost písmen někdy dokonce i barevné rozlišení. Tento standard ovšem není nikde stanoven, natož dodržován. Je si ovšem také nutné uvědomit, že tyto nastavení se budou lišit ve Windows při 640 × 480 a 1920 × 1440.

Malý příkládek⁰

Win9x 640 × 480, standardní nastavení, standardní velikost písma

stejné Win9x, ale jiné rozlišení, standardní nastavení, standardní velikost písma

Je vidět, že velikost okna se nijak nezměnila, ani pozice jednotlivých komponent se nezměnila, přesto formulář vypadá zcela odlišně – i vcelku nefunkčně, protože některé funkční prvky nejsou vůbec viditelné. Popisky u tlačítek či labelů jsou uřezané. Nejhorší co ještě k takto naprogramovanému formuláři může autor udělat je nastavit ho tak, aby nešla změnit jeho velikost. Pak už tedy zbývá jen jediná možnost a to udělat to real-timeově jinou aplikací, což ovšem nemůžete chtít po obyčejném uživateli. Spíše by si stačilo jen uvědomit, že i manuální nastavování aplikací při každém spuštění je dosti otravné, obzvláště když se to dá vyřešit jinak. 

Aby jste mě neosočovali, že jsem schválně svolil extrémní rozlišení, tak zde je ještě jeden screen shot. Doufám, že z něho už je také zřejmé, že problémy začínají už od rozlišení 1024 × 768.

stejné Win9x,  rozlišení 1024 ×768, standardní nastavení, standardní velikost písma 

Z předchozích obrázků není zřejmá ještě jedna zajímavá vlastnost - chování a to autoSize. Jak víte některé komponenty ji mají jiné ne. Takže například pokud by v tomto příkladu byl nějaký CheckBox, pak by jste jeho text asi mohli jen odhadovat, protože by jste viděli asi tak zhruba polovinu výšky a polovinu délky :-). 

Pár závěrečných rad

• nutno poznamenat, že i když tak okna z příkladu vypadají stejně velká, tak ve skutečnosti na monitoru stejně veliká nebudou. S tím souvisí i jejich čitelnost, proto je vždy dobré zvolený design formulářů vyzkoušet v různých nastaveních. Příklad PCWorld v rozlišení 1024 × 768, přečtěte si popis programu.
• každý formulář musí mít vždy definovanou proceduru onResize, onConstrainResize (Delphi6) a onPaint, pokud používáte nějaké nestandardní prvky na formuláři či přímé vykreslení.
• každá procedure onResize musí obsahovat nastavení velikosti jednotlivých komponent, ať už využitím funkce autoSize či manuálním nastavením (zde musíte sami nastavit height a width). Nezapomeňte na to, že při manuálním nastavení nemůže odhadovat height a width, ale můžete použít již nastavené komponenty, Canvas.textHeight či Canvas.textWidth.
• každá procedure onResize musí obsahovat nastavení pozice všech komponent. Zde budete docházet k problému jednotného odsazení komponent např. při rozvržení do sloupců, které se dá vyřešit asi jedině, tak že si projitím všech možností předem zjistíte nejdelší komponentu v předcházejícím sloupci. Nedoporučuji to udělat staticky, tak že se při programování podíváte, která komponenta má nejvíce písmen či je nejdelší a podle ní to nastavíte. Protože Vy i někdo jiný může vytvořit například lokalizaci dané aplikace či někdo bude používat jiné fonty aj. 
• malý příkladek toho, jak by mohla být napsána procedure onResize. Možná to vyznělo z mého textu špatně, ale procedure onResize není nutné mít přiřazenou po celý běh aplikace, pokud se nedá změnit velikost daného formuláře. Změní-li uživatel vzhled obrazovky, když máte spuštěnou aplikaci, pak Vaše formulář obdrží zprávu na onConstrainResize a onPaint. 

Závěr

Takže ať chcete či ne, tak RAD Vám zase tak moc práce na finální podobě aplikace neusnadní, místo nějakých 7 + n řádek² budete muset napsat minimálně 4 či 2 řádky pokud komponenta podporuje autoSize. Ale právě u těch řádek, které zbudou na vás, se pořádně zapotíte. Je to absolutně nudné a zdlouhavé.

Jediné místo, kde Vám RAD ušetří všech 7 + n řádek asi budou jen Vaše debug aplikace.

A jak vypadá praxe? Ten kdo jako já se pohybuje v rozlišeních nad 1024 × 768, tak to ví asi moc dobře sám, a ten kdo to nevím, ať si to vyzkouší :-) 

---

⁰ příklad byl převzat od Marco Cantù z knihy Mistrovství v Delphi
¹ ve starších verzích Delphi se to řešilo public deklarací procedure GetMinMax (var MinMaxMessage: TWMGetMinMaxInfo); message wm_GetMinMaxInfo;
² create, name, parent, left, top, height, width + n na změnu defaultních hodnot