Lapforrás

<cim cim2="Windows Presentation Foundation" cim3="Windows Forms Reloaded" prev="" back="Kezdolap" next="" kep="hz_csik.png" szerzo="hz|Hernyák Zoltán"/>


= WPF alapok =

A '''Windows Presentation Foundation''' ('''WPF'''), ez az új windows programozási platform. Ennek segítségével lehet igazán látványos, animácókkal és egyéb elemekkel ellátott, erősen designelt alkalmazásokat fejleszteni.

== WPF Futtatási igények ==


A WPF fejlesztéséhez és futtatásához szükséges a Microsoft.NET Framework 3.0, vagy annál újabb verzió. Részleges támogatás a Visual Studio 2005-ben elérhető add-on telepítésével. A teljes támogatást a Visual Studio 2008-ban integrálta a Microsoft.

Hardware vonalon látni fogjuk, hogy DirectX igények merülnek fel. A DirectX-re jellemző, hogy nem megfelelő hardware alapokon képes funkciókat limitálni a teljesítmény-visszafogás végett, illetve nem megfelelő videókártya támogatás mellett bizonyos funkciókat szoftveresen helyettesíteni. Ez utóbbi természetesen a processzor terhelését fogja emelni. Ugyanakkor egy megfelelő videókártyával ellátott kliens gépen automatikusan a legjobb teljesítmény kihozására képes a processzor számottevő terhelése nélkül.

== Kis történelem ==

Korábbi verziókban (Framework 2.0, Win32 API) a windows alkalmazásfejlesztés két alappilléren nyugodott:

* User32, ami a hagyományos nyomógomb (button), kiválaszt elem (checkbox), stb vezérlő elemeket támogatta
* GDI/GDI+, ami a szokásos 2D alap grafikai támogatást adta (vonalak, szövegek, képek, stb)

A fenti páros a Win32 API része volt, mely az első 32 bites windows verzióban, a Win95-ben jelent meg először. Közel 12 éve lényegi változás ezen a vonalon nem következett be. Minden windows alkalmazásfejlesztő platform legvégül ezekre a komponensekre mutatott. Még a .NET Framework-beli Windows alkalmazások is ezeket a Win32 komponenseket használták fel, wrapper osztályokon keresztül. Ezen wrapper osztályok a standard framework részét képezték, és elrejtették ezt a tényt a framework programozók elől, de egyúttal be is korlázozták a korábbi framework lehetőségeit.

A MS már korábban is megalkotta a DirectX motort, melyet elsősörban a játékfejlesztők használtak ki. A DirectX komoly teljesítményelőnyökkel rendelkezett a GDI/GDI+ megvalósításokkal szemben, mivel maximális támaszkodott a videókártya képességeire. A DirectX első verzói a Windows '95 után nemsokkal jelentek meg, és a fejlesztése azóta is folyamatos. A MS együttműködik a videókártya gyártó cégekkel, és ezen együttműködés hatására mind a DirectX teljesítménye javul folyamatosan, mind a videókártyák fejlesztési iránya tud reagálni a szoftveres igényekre.

A WPF megjelenítő motorja nem a GDI/GDI+, hanem a DirectX. Ez jelentős módosítás, hiszen a GDI/GDI+ kiváltásával a User32 is kiváltásra kerül. Vagyis a WPF-ben fellelhető vezérlők alapjai már nem a User32-ben vannak leprogramozva, hanem nulláról kerültek újraírásra a Framework-ben. Ezen újraírás közben természetesen a funkcionalitás megőrződött, viszont néhány, az évek során előkerült hibás vagy zavaró működési rendellenességek javításra kerültek. A WPF (pontosabban a DirectX) igényli, hogy a videókártya ne legyen túl öreg, illetve a drivere se legyen az. A WPF képes '''Windows XP'''-n is futni, mivel arra mind a DirectX, mind a Framework telepíthető. A leirat szerint a videókártya drivere ne legyen öregebb mint 2004, amikor is a MS kiadott egy driver fejlesztői iránymutatót, és a videókártya-drivertől ezen irányelvek betartását elvárják. Hírek jelentek meg, hogy csak a DirectX 10-el képes együttműködni a WPF. Ez nem igaz. A '''DirectX 9'''-es verziója is tökéletesen megfelel, ezzel a verzióval is teljes mértékben képes a WPF együttműködni.

A WPF kódból kideríthető, hogy a WPF milyen fokozatban képes egy adott gépen a futásra. 3 szintet lehet megkülönböztetni:
* 0. szint: a videókártya semmilyen HW támogatást nem képes adni, a WPF-nek (és a DirectX-nek) mindent szoftveresen kell megoldani.
* 1. szint: részleges támogatás
* 2. szint: teljes támogatás

Egy adott esetben a támogatási szint lekérdezhető az alábbi kóddal:

<code lang="csharp">
int szint = (System.Windows.Media.RenderCapability.Tier >> 16);
switch(szint)
{
    case 0: ....; break;
    case 1: ....; break;
    case 2: ....; break;
}
</code>

Az alkalmazásfejlesztőknek korábban is lett volna lehetőségük a Windows alkalmazások fejlesztéséhez DirectX motort használni, hiszen az képes nem csak full-screen, hanem ablakos módon is működni. Voltak is erre kezdeményezések. Ugyanakkor a DirectX programozhatósága nagyon rossz, nehezen illeszthető össze a hagyományos alkalmazásfejlesztési logikával. A programozóknak nagyon sok munkát kellett belefektetni a felület megtervezésébe és kivitelezésébe, melyhez semmilyen támogatást nem kaptak a GDI/GDI+ vagy a User32 irányából, lévén azok a DirectX-el nem álltak semmilyen kapcsolatba. Ez akkora problémát jelentett, hogy végül is nem készültek ilyen jellegű alkalmazások (a játék-kategóriát leszámítva).

A WPF ezt szerencsére alapjaiban megváltoztatta. A WPF vezérlők a Visual Studio felületén keresztül hagyományos módszerekkel a form-ra feltehetők, méretezhetők, tulajdonságaik beállíthatók. Az, hogy mögötte a kirajzolsát DirectX végzi - a programozónak nem kell feltétlenül tudni, és általában nem is veszi észre.

Persze a DirectX jelenléte, valamint a megjelenítés újragondolása további jelentős változásokat is hozott:

* '''WEB-szerű elrendezés''': a MS próbálta a web-en (böngészőben) használt lapelrendezési, lapösszeállítási lehetőségeket a WPF-be beépíteni. Ezek beváltak, mindenki ismeri és kedveli őket. A Windows Forms korábban a X,Y koordináta alapú elrendezést követte, a kontrollok a form adott pontjára kerültek fel, és a form átméretezésének kezelése állandó problémát jelentett. Új vezérlők jelentek meg a WPF-ben, amelyek tárolók (Container) funkciókat látnak el, és képesek reagálni a form átméretezésére, újrarendezvén a saját tartalmukat.
* '''Gazdag rajzoló modell''': a DirectX és a videókártya által ismert grafikai fogalmak (textúra, átlátszóság, stb) szintén belekerültek a vezérlők alakjába. A programozók könnyedén tudnak ezekkel az elemekkel is dolgozni akár kódból, akár design-ból.
* '''Gazdag szöveg''': támogatás jelent meg magasabb szintű szövegkezelésre, beleértve a megjelenítendő szöveg stílusozását, grafikák beillesztését, hasábok és bekezdések kezelését, igazítását, stb.
* '''Animációk''': egyszerű animáció-modell került beépítésre, melynek segítségével a kontrollok vagy egyéb primitívek elforgathatók, átszinezhetők, egyéb módon módosíthatók. A módosítások sorozatát (Storyboard) és időzítését (Timeline) megadván az animáció végrehajtását a DirectX motor fogja elvégezni, ennek megfelelően a programozó mentesül az animációk kivitelezését végző kód kódolásától, és az animáció teljesítménye (sebessége) is megfelelő.
* '''Audió és videó''': a Windows Media Player által felismert formátumú média file-ok az alkalmazásba könnyedén beilleszthetőek, és lejátszásuk teljes körűen vezérelhető.
* '''Stílusok és sablonok''': támogatás a skinezésre, akár csak WEB-es alkalmazás esetén. A sablonok segítségével a vezérlők bármely részének kinézete módosítható (pl. egy görgdítősáv csúszkája is felstílusozható, akár a többi darabkától függetlenül).
* '''Parancsok''': parancsok definiálhatók, melyekre a vezérlők felprogramozhatók, és a parancs kiadására tudnak reagálni.
* '''Deklaratív tervezés''': a felhasználói felületet XML file-ban lehet leírni, a kód fejlesztésével párhuzamosan, tőle függetlenül. Vagyis a programozó kódolhat nyugodtan, míg a designer megtervezi a felületet, skin-eli, ellátja animácikkal. Ez a WEB alkalmazások fejlesztése során felmerült módszertan alkalmazása a Windows Forms alkalmazások fejlesztésére.
* '''Lapozható alkalmazások''': olyan alkalmazások fejlesztése, amelyek működése, külalakja hasonlít a böngésző működéséhez, vagyis a program kezelője könnyedén el tudja azt sajátítani. Néha a hasonlóság olyan nagy, hogy a kezelő azt hiszi, hogy az alkalmazás a böngészőben is fut ténylegesen.

== Felbontás-függetlenség ==

'''Felbontás-függetlenség''': a WPF alkalmazás vektorgrafikus, vagyis átméretezés, képernyő DPI átállítás esetén a Form megjelenítés nagyítódhat, de ez nem pixeles nagyítás, hanem vektoros nagyítást jelent. Ez az előny pl. az alkalmazás nyomtatásakor is kihasználható.

A WPF-nek saját elképzelése van a mértékegységekről. Egy vezérlő méretét nem pixelpontban, nem milliméterben kell megadni, hanem WPF egységekben. A WPF mértékegysége a DIU (Device Independent Unit), ami egyébként az inch (2.54 cm) 96-od része. Ez azt jelenti, hogy az átlagos monitorokon, ahol a DPI értéke szintén 96, a WPF egységek 1 pixelpontot képviselnek. 

  Fizikai méret = DPU egységekben megadott méret  * DPI beállítás értéke.

Vagyis ha egy vezérlőnk 100 egység széles, akkor egy 96 DPI mellett ez 100 pixelpont szélességet jelent. Ha a felbontást 120 DPI-re veszük, akkor a vezérlőnk automatikusan 120 pixelpont méretűre nő meg (és természetesen a tartalma ugyanúgy). Vagyis ha a vezérlőnk egy nyomógomb, akkor a gomb felirata is megnő vele együtt. Mivel a tartalom is pixelgrafikusan nőtt, nem kell félni attól, hogy a jól megtervezett és belőtt kinézete az alkalmazásnak most szétesik, a gomb felirata ki fog lógni a gomb területéről, stb. 

Jegyezzük meg, hogy a WPF a konkrét méretek kiszámítását a rendszer DPI beállítására alapozza, nem a képernyő felbontására. Ha a gépünk 120 DPI-n fut, akkor 1 WPF egység 1.25 pixelpontot fog jelenteni. Hogy a tört értékek kerekítgetései ne okozzanak zavart, a WPF mindenütt tört értékekkel számol (double). Ez jelentkezik az animációk lépéseinek kiszámításában (elforgatás, ...), illetve a minden egyéb ponton is.

A problémát a pixel alapú grafikus képes jelentik (bitmap). Ezek átméretezése azok minőségének romlását jelentik. Ezért javasolt, hogy ahol csak lehet, vektorgrafikus formátumot használjunk.

== Hagyományos Windows Forms ==

Nagyon sok kód épül már a régi alapokon nyugvó Windows Forms technikákra. Ezek kiváltása időbe kerül, tehát a WPF alkalmazások inkább az új kezdetű projectekre lesz jellemző. Másik fontos észrevétel, hogyha egy project célja grafikailag alacsony teljesítményű kliens gépeken is futó alkalmazások elkészítése, akkor nem biztos hogy a WPF választása célszerű. Ezért továbbra is jellemző lesz a hagyományos Windows Forms alkalmazások fejlesztése (továbbfejlesztése). A régi platform tehát sokáig jelen lesz még.

A DirectX fejlődése természetesen nem fog megtorpanni, a WPF ehhez csak újabb lökést adott. Továbbra is jellemző lesz a natív DirectX programozás, ahol annak teljesítményét az utolsó százalékig ki kell facsarni.

A WPF kapcsán egy másodlagos, de nagyon fontos project is elindult, a WPF/E (WPF Everywhere, WPF mindenhol). Ezen projectet közben Silverlight névre keresztelték át. Célja olyan alkalmazások fejlesztésének támogatása, amely böngészőben fog futni (web oldalak részét képezi), de hasonló grafikai teljesítménnyel és lehetőséggel rendelkezik, mint a WPF maga. Ennek megvalósítása már erősen előrehaladott állapotot tükröz, Windows operációs rendszeren és Internet Explorer böngészővel kiválóan működik. Készül más böngészőhöz is a plugin, ami lehetővé teszi a Silverlight alkalmazások futtatását. Ez persze azt is jelenti, hogy ugyanazon alapokon nyugvó technikával lehet majd web-re, és windows forms-ra is fejleszteni, vagyis a programozóknak nem kell sok újat tanulni. 

== A WPF felépítése ==

[[Kép:WPF_Architecture.png]]

* '''PresentationFramework.dll''': a legfelsőbb szint, ezt használjuk fejlesztés közben. Ebben vannak implementálva a vezérlők (nyomógomb, panel, ...), a stílusok, stb.

* '''PresentationCore.dll''': az előző, legfelső réteg számára hordozza az alap osztályokat, mint az ''UIElement'', ''Visual''. Ezen osztályokból származnak a formák (shape), vezérlők (controls). 

* '''WindowsBase.dll''': a WPF alapvető működése végett fontos objektumosztályokat tartalmazza, mint pl. a ''DispatcherObject'', vagy a ''DependencyObject''.

* '''milcore.dll''': a WPF motor magja. A magasabb szintű grafikus elemeket (vezérlők, egyéb vizuális elemek) fordítja át DirectX grafikus elemekre (háromszögek, textúra). 

* '''WindowsCodecs.dll''': alacsony szintű API elsősorban képek (bmp, jpeg, ...) feldolgozására, manipulálására.

* '''Direct3D''' alrendszer jeleníti meg a milcore által megadott grafikus elemeket a képernyőn.

* '''User32''' a user inputot kezeli, és irányítja. Korábban a GDI/GDI+ motor alatt a vezérlők megjelenítéséért is felelt, de a WPF esetén ezen funkciója már nincs kihasználva.

== A WPF legfontosabb alaposztályai ==

A WPF névterek a '''System.Windows''' névtérben helyezkednek el. Kivételt képez a ''System.Windows.Forms'' al-névtér, amely a hagyományos GDI/GDI+ alapú vezérlőket tartalmazza.

===  System.Threading.DispatcherObject ===

A WPF alkalmazások egyszálú (single-thread affinity, STA) modellűek. Vagyis minden egyetlen szál vezérli a teljes felhasználói felület működését. Másik szálból módosításokat végezni a felületen, vagy olyan tevékenységet végezni, amely módosítást eredményez - nem biztonságos!

A DispatcherObject leszármazottjai képesek detektálni, hogy a módosítás a tulajdonos szálból érkezett-e, vagy sem. Ha nem, akkor automatikusan továbbítják a kérést (függvényhívás) a megfelelő szálba.

=== System.Windows.DependencyObject ===

A WPF elemek egy erőteljes property alrendszert birtokolnak, ahol valamely property értékének megváltozása képes továbbgyűrűzni lefele, triggereket kiváltani, stb. A property értékek egy-egy ilyen dependency object példányban vannak tárolva.

=== System.Windows.Media.Visual ===

Minden látható elem alapköve ezen osztály. Minden példánya egyetlen kirajzolható ''valami'', amely tartalmazza magáról a kirajzolási utasításokat, egyéb beállításokat (átlátszóság, ...). Ezen osztályon keresztül képes a milcore.dll értelmezni a WPF vezérlők működését is. Minden olyan ''valami'', ami meg kell jelenjen az ablakban, ezen ős osztályból kell származzon.

=== System.Windows.UIElement ===

A focus, események, input fogadásának támogatása. Minden vezérlő alapja.

<alairas>Hernyák Zoltán</alairas>