Siin ta on. Kunagi sai kirjutatud. Ma ei ole seda hetkel lugenud, aga arvatavasti seal midagi väga marginaalselt valet pole.

 

Erti-Chris Eelmaa

Ülevaade WPF tehnoloogiast.

 

 

Sissejuhatus WPF’se.

Tänapäeval oleme jõudnud punktini, kus on ääretult palju tähtsust kasutajalidese mugavusel ning välimusel.  Mugavust on eelkõige vaja, et kasutajad saaksid kiiremini aru, mida applikatsioon teeb ning kuidas. Selle jaoks on ka Webmeedias Visuali tiimis inimesi. Igat visuaalset detaili lihvitakse hoolikalt, isegi väike vari võib kasutaja kogemust muuta drastiliselt. Inimesed arutavad läbi iga viimsegi olukorra ja hoolitsevad selle eest, et võhikust inimene saaks kõigega hakkama. Enam ei ole ainult programmeerijaid. Isegi, kui kood on hea, kiire, siis ei tähenda see, et rakendus saab kuulsaks. Selleks on vaja veel Visuali inimesi, kelle kujutusvõime on piiritu.

Hetkel on olemas kaks peamist „tehnoloogiat“, et arendada graafilisi rakendusi. Nendeks on:

• Windows Forms(winapi)
• Windows Presentation Foundation(WPF)

Windows Forms on juba väga kaua eksisteerinud, samas WPF on alles hiljuti tekkinud(Windows Framework 3.0’ga). Formsi probleem on selles, nimelt, et tal on väga vähe painduvuslikku, see tähendab seda, et kõik kasutajaliidesed näevad välja monotoonsed, need mis ei näe, nendega on VÄGA palju vaeva nähtud. Põhjus on just selles, et Windows forms kasutab GDI(graphics device interface), mis on väga vana tehnoloogia. See miks windows forms kuhugi ei arene, on põhjustatud arhitektuurist, kus peal ta on. Seda ei saa lihtsalt uuendada. Formsis on olemas „häkke“, mille abil saame siiski ka väga ilusat kujundust, kuid mis nõuab tohutult aega. Muidugi võib tulla välja, et meie kujundus ei tööta igal arvutil nii nagu sooviksime.

Kuna GDI funktsiooni kutsung käib läbi mitmete kihtide, siis on see ka aeglane tehnoloogia, tähendab, kohe kui tahta midagi veidikenegi võimsamat teha, tuleb ette kiiruse tala. Tegelikult ongi Windows Forms ainult „wrapper“, et me saaksime kasutada GDI’t. On olemas ka teisi graafilisi kujundamisteeke, kuid ka need on ainult „wrapperid“ GDI ümber, mis meid ei aita.

Microsoft on teadlik nendest probleemidest ning selleks pakkus ta välja uue tehnoloogia, mis on jõudsalt arenenud. WPF, Windows Presentation Foundation, tuli välja aastal 2006(.NET framework 3.0’ga). WPF on andnud meile meeletu võimsuse peaaegu kõige üle. Sellega läheb natukene aega, et käppa saada, aga kui käpas, siis on see täiesti seda väärt. Saavutatud on kena UI loogika ning välimuse eraldatus. See tähendab seda, et kui meile meeldib mingi graafiline element(nupp, slaider, checkbox), siis me saame selle välimuse täielikult ümber teha, WinFormsis on see pea võimatu. Kuna WPF kasutab nüüd DirectXi(mängude tegemise teek), siis on saavutatud tõeline kiirus. Enamus funktsioone ei lähe läbi GDI enam, vaid DirectX ning graafikadraiver saavad suhelda otse, see on meeletu kiiruse võit. Kuna DirectX toetab graafika kaardi peal renderdamist, siis on väga paljud asjad hardware accelerated(„riistvara kiirendatud“ – laseme vidoekaardil tööd teha). Kui videokaart ei toeta seda, siis WPF läheb automaatselt tarkvaralisele renderdamisele(ehk protsessori pealt).  Olen kasutanud mõlemat tehnoloogiat ning võin kindla sõnaga öelda, et mina ei taha kunagi windows formsi kasutada. WPF teeb programmeerimise lõbusaks!

 

 

Mida head pakub WPF?

• Hämmastav tehnoloogiate ühendamine – vanasti, kui tahtsid kasutada video/hääletuvastamis/jms APISI, tuli õppida selleks väga palju erinevaid asju, kuna tegu oli erinevate tehnoloogiate ning interfeissidega. WPF on ühendanud kõik üheks ning peaaegu kõigel, mida WPF pakub, on integratsioon meeletu. Me saame panna video mängima kõikjale. Teeme 3d kuubiku ja paneme selle keerlema, samal ajal paneme video ühele kuubiku tahule ning tekitame sellele tahule nupud „Mängi“, „Peata“. Kõlab nagu hulk tööd, kuigi reaalsus on see, et selle saab 10 minutiga ära teha. Miskit mida Winformsis umb nädalaga teed, kui sedagi.
• Programmeerijate ning kujundajate parem eraldus – WPFil on kujundamiskeeleks XAML, see tähendab, et kujundus ning reaalne äriloogika kood saavad üksteisest eraldi areneda. Kujundajad saavad rohkem panustada, kui lihtsalt pilte, nad saavad seda ise teha, ning ka lisada XAMLIs animatsioone. Selleks ei pea kujundajad üldse koodi kirjutama. Extensible Markup Language on XML taoline keel,  millega saab peaaegu kõike kujunduse trikke teha, ilma koodi(code-behindi) kasutamata.  XAMLi haldamine on eelduseks, et kasutada MVMMi tehnoloogiat.
• Resolutsiooni sõltuvus – Formsis oli nii, kui said ühe resolutsiooniga&kuvariga kõik ilusaks, siis asi võis minna väga inetuks resolutsiooni vahetusel. Kuna pixel varieerub resolutsioonist, siis on see ka loogiline. WPF ei kasuta pixleid, vaid resolutsioonist sõltumatuid ühikuid(device Independent units – DIU). 1 DIU = 1/96 tollist. Siiski ei ole see nii lihtne, seda saavutatakse ainult, siis kui kasutaja on määranud windowsi sätetest reaalse DPI(Dots per inch – piksleid tolli kohta), mis vastab kuvari hetkelisele olukorrale. Seega võib see varieeruda, ehk 1 DIU ei ole alati 1/96 tolli, vaid mõnel kuvaril erinev, kuid tavaliselt on see ikkagi sama. Kui viia rakendus ühelt kuvarilt teisele, siis ei juhtu mitte midagi muud, kui, et rakenduse tekst võib minna selgemaks/hägusemaks. Kuna WPF kasutab enamus kohtades vektorgraafikat, siis jäävad elemendid ilusad.
• Riistvaraline kiirendamine(hardware acceleration) – Nagu ennist öeldud, kuna WPF jookseb DirectX peal, siis saab GPU päris palju tegevust, see on muidugi õige, tänapäeval on GPUd väga võimsad ning milleks tülitada protsessorit mõttetu juraga, millega GPU saab mitmeid kordi paremini hakkama ning ta selleks loodud ongi. Kui see ei õnnestu, on olemas alati tarkvaraline renderdamine.
• 3D toetus – väga lihtne on tekitada 3D stseen ja seal kasutada erinevaid visuaalseid elemente ning neile veel külge panna interaktiivsus, seda otse kujundamiskeeles, ei ühtki rida koodi. Kuigi arenenud mängu ei soovita Microsoft WPFiga teha, vaid otse DirectX, siis lihtsamate 3D mängudega saab WPF hakkama. WPF kapsuleerib erinevused videokaartide vahel ära(erinevaid videokaarte on testitud juba Microsofti poolt), samas „otse“ DirectX kasutades pead sa ise hakkama vaeva nägema, sest kõik videokaardid ei toeta samu asju, mõned on vanemad, mõned uuemad. Kui hakkad DirectX mängu tegema, pead enne paika panema nõuded, mida sa tahad, et eksisteeriks.

 

 

 

 

WPFI jõudne areng freimwõrkide vahel

• DirectX sissepanek WPF applikastsiooni otseselt, vanasti sai seda teha ainult kasutades HWND tüüpi, st DirectX content oli alati kõige pealmine, aga nüüd saab eristada, kas DirectX on peal või mitte.
• Parem data bindimine – meeletult hea funktsioon, mille abil saame ühendada andmed kasutajaliidesega. Bindimisel on väga palju valikuid, kaasa arvatud eraldiseisev valideerimine, tulemuse formaatimine, konverterite kasutamine, bindimise suundade määramine(kas UI element saab oma andmeid muuta) jms.
• Paremad effektid – alguses oli kaasas BitmapEffect klass, kus oli hulgaliselt effekte, aga see oli ikka väga aeglane. Microsoft eemaldas selle klassi ning asemele pakkus raudvara kiirendatud pixelshader effekte, mis on mitmeid kordi kiiremad ning näevad visuaalselt paremad välja. Effektide alla kuuluvad asjad, mille abil saab tekitada peaaegu kõigele nii sisemisi kui välimisi varjusi, glowe, blure jms.
• WPF on muutunud võimsamaks partial-trust keskkonades. Need on keskkonnad, kus kasutajale on antud osalised õigused. Võimsamaks tähendab siin seda, et kasutaja saab kasutada rohkem WPF funktsionaalsust.
• Multi-Touch tugi – me saame ligi kõiksugu eventitele, mis puudutavad multitouchi, nagu näiteks  keeramisele, skaleerimisele, liigutamisele. Tänu sellele saame teha rakendusi, mis on väga interaktiivsed ning pakuvad kasutajale meeletu kogemuse.
• Windows7 pakub uusi võimalusi ning WPF toetab neid, uuteks võimalusteks võime lisada näiteks Jump liste(taskbari ikooni peale parem klikk ning seal on näha valikud „Pin this program to taskbar“ jms. Neid saame ise tekitada, kui ka muuta. )
• Uued kujunduselemendid – DatePicker, DataGrid, Calendar
• Animatsioonid on WPFis väga võimsad, nende abil saame tekitada kasutaja reaktsiooni „WOW“, alustades sellest, et rakenduse peaake avaneb nii, et me animeerime peaakna läbipaistvust, alustades sellest, et see on täiesti läbipaistev ning ajaga läheb ta täiesti läbipaistmatuks. WPF on lisanud erinevaid ajafunktsioone. Kas me teeme seda lineaarselt, eksponentiaalselt, või äkki kuubiku meetodiga?(alguses kiirelt, siis aeglaselt ning uuesti kiirelt).
• Kui kasutame pilte WPF’is(png/jpg/midaiganes), siis tekib tihti olukord, et pilt näeb välja väga halb – ta on udune. Seda põhjusel, et kuna WPF ei toimi pikslite baasil(vaid tollide), siis tegelikult on WPFIs mõiste subpixel, tähendab, tekib blending ning sageli jätab see väga halva tulemuse. Selleks on WPFil nüüd olemas funktsioon „UseLayoutRounding“, mis tähendab, et kõik asjad „snapivad“ pikslite külge, andes meile ilusama tulemuse. Seda sama asja kasutatakse ka selleks, et tekitada 1 pikslised raamjooned, mis muidu jäävad silmale udused.
• Tekst on aja pikku paremaks läinud. WPFi üks probleemidest oli see, et tekst oli väga udune mõndades kohtades(st kuvaritel), näiteks oli aru saada väga lihtsalt, et kas tegu on WPFi rakendusega või mitte, kui vaatasid teksti. Nüüdseks on see parandatud ning WPF suudab peaaegu sama ilusat teksti renderdada, kui GDI.

 

 

Dependency properties

Property C#’s pole mitte midagi muud, kui wrapper ühe konkreetse muutuja ümber. Wrapper on meile kasulik kuna me saame sinna panna programmispetsiifilist loogikat, mis käib antud muutuja kohta, me saame kontrollida, kes saab muutujat muuta ning tekitada valideerimine. Enne propertite olemasolu kasutatati lihtsalt funktsioone, mis konkreetse muutuja kohta käisid(st getVariable() ning setVariable(arguments)) , aga esiteks oli see tülikas ning teiseks tekkis overhead – funktsioonide kutsung võttis aega. Kuigi, kui WPF tuli, siis pidi Microsoft välja töötama uuema property süsteemi, selle süsteemi nimi on Dependency property system.

Mida lahendas see süsteem? Kui kujutada ette klassi, kus on X arv muutujaid, siis klassi instantsi loomisel inistialiseeritakse iga muutuja kohta mälu. See on praktiliselt lubamatu, sellepärast, et suvaline UI element pärineb baasklassidest, mis omakorda pärinevad baasklassidest ja nii edasi kuni  7 levelit. Iga level võtab tohutult mälu. Võib ette kujutada, et meil on 30 nuppu, igal nupul on omadused(suurus, font, värv, jms), kuigi reaalsed väärtused on neil kõik samad, aga mälu võetakse ikka 30 nupu eest. Sellepärast tegi Microsoft nii, et kõik dependency propertied samade klasside vahel on üksteisega jagatud. Kui nuppude andmed on erinevad, siis hoolitseb WPF selle eest, et mälus oleks 2 erinevat olekut. Kasutaja ei pea teadma midagi, mis reaalselt toimub. See hoiab mälu meeletult kokku.

Kui tahame XAML’is bindida, tuleb bindida dependency propertite vastu(või property peab ise implementeerima InotifyPropertyChanged interfeisi). Dependency propertite vastu tuleb sellepärast bindida, et need juba ise implementeerivad teatud eventid, mida on XAMLil vaja, et oma andmeid reaalselt uuendada. Nendeks eventiteks on nt: „propertit uuendati“, „propertit vahetati“.

Kõige parem on see, et lõppkokkuvõttes näevad dependency propertit täpselt samasugused välja nagu tavalised C# propertid.

Kuidas implementeerida Dependency propertit?

public static readonly DependencyProperty IsEnabledProperty =

DependencyProperty.Register(

“IsEnabled”, typeof(Boolean),

 

);

public bool IsEnabled

{

get { return (bool)GetValue(IsEnabledProperty); }

set { SetValue(IsEnabledProperty, value); }

}

 

IsEnabled property implementatsioon. Siit on näha, et DP property ise on staatilisena deklareeritud(siis võtab ainult ühe korra mälu). Hiljem property süsteem hoolitseb selle eest, et kui klassil on vaja erinevat väärtust, kui default väärtus, siis ta selle ka loob ilma teisi klassi instantse segamata.

Hea tava on mitte panna loogikat set{} vahele, kuna property süsteem võib muuta väärtusi läbi SetValue funktsiooni otseselt. Kui vaja oma loogikat, siis tuleks .Register funktsiooni parameetreid.

Data binding

WPF laseb meil väga väikese vaevaga kokku „sulatada“ kaks komponenti. Kui komponentidel on vaja hoida üksteist sünkroonis läbi ühe muutuja, siis on binding selle jaoks mõistlik. Tavaliselt kasutatakse bindigut just sellepärast, et UI element hoida sünkroonis „code-behindis“ oleva muutujaga. Kui see muutuja muutub, siis peaks UI sellest kohe teada saama ning vastavad muudatused tegema.

Näiteks võib võtta, et meil on listbox, kus sees on asjad. Need andmed on binditud mingisuguse code-behindis oleva massiivi vastu. Nii pea, kui me seda massiivi muudame, nii pea uuendab ka graafiline pool ennast. Seal ei ole mingeid vahepealseid nõkse, vaid nii lihtne see ongi. Me ei pea vaatame evente, ega midagi muud.

 

Kui implementeerida ise „Add item“ funktsioon, siis näeb see välja midagi sellist(pseudo):

void btnAddItem(object sender, RoutedEventArgs e) {  datacollection.Add(editbox.Text);  }

Ja kohe uuendub iseenesest ka listbox. Tänu bindingule, kusjuures binding on massiivi/listi vastu, mis peaks ise implementeerima InotifyCollectionChanged interfeissi(kui asju lisame/kustutame massiivist) või siis hoidma oma asju listis BaseObservableCollection<type>, mis teeb enamus tööd ise ära. Juhul kui tahame, et listbox uueneb ka siis, kui me muudame olemasolevaid andmeid(näiteks Tea=>Tee), siis  peab iga massiivi element omakorda implementeerima InotifyPropertyChanged intefeissi, või kui võimalik, siis kasutama dependency properteid.

Bindimise kõige suurem pluss on see, et me võime bindida igatmoodi. Võimalik on bindida mitmete propertite vastu ning siis kasutades konverteri, lastes välja ühe konkreetse väärtuse. Võime bindida ükskõik millise objekti vastu, selleks võime Visual trees ülespoole liikuda, kui vaja.(Relative binding).

Binding võib olla kahe või ühesuunaline. Kahesuunaline tähendab seda, et UI võib sama propertit muuta, kuhu vastu ta binditud on. See on kasulik näiteks, siis kui meil on kasutusel editBox ning sinna saame kohe kirjutada valideerimisloogikat dependency property juurde.

Stiilid, ControlTempliidid

WPFi üks kõige tugevamaid külgi on see, et UI loogika ning välimus on täielikult eraldatud. Kui meile meeldib mingi elemendi loogika, siis võime ta välimuse täiesti ära muuta. Võime panna nupu peale ümberpööratud video, mis mängib koos häälega, seda vaid paari reaga.

Kohati on meil vaja, et kõikidele ühesugustele elementidele kehtivad samad reeglid. Näiteks tahame, et kõikidel nuppudel olevad tekstid oleksid sama suured ning samasuguse fondiga.

 

Siit on näha kuidas on muudetud olemasolevat nuppu, pandud talle teistsugune font ning tagataustaks gradient.

Kui tahame kõikidele nuppudele ühte stiili rakendada, tuleb ainult paar rida kirjutada:

    <Window.Resources>

        <Style TargetType="Button">

           <Setter Property="Background" Value="Orange" />

           <Setter Property="FontStyle" Value="Italic" />

           <Setter Property="Padding" Value="8,4" />

           <Setter Property="Margin" Value="4" />

        </Style>

    </Window.Resources>

Siin on aga nõks, Button saab neid atribuute ise kah muuta, st Button on võimsam kui stiil, ta võib omale panna Backgroundiks Musta. Kui Button ei pane mingit backgroundi, siis ta saab by-default „Orantši“ tagatausta.

See ei ole muidugi kõik, mida stiilidega teha saab. Stiilid tegelikult ei ole ainult selle jaoks, et teatud väärtusi muuta. Stiilidega saab nupu välimust muuta teadmatuseni, kusjuures me saame stiilis ka nupu loogikat ümber kirjutada. „Mis juhtub, kui vajutada nupule?“ ja nii edasi.

Selleks peame minema kallale nupu Template propertile.

<Style TargetType="Button">

    <Setter Property="Template">

        <Setter.Value>

            <ControlTemplate TargetType="{x:Type Button}">

                <Grid>

                    <Ellipse Fill="{TemplateBinding Background}"

                             Stroke="{TemplateBinding BorderBrush}"/>

                        <ContentPresenter HorizontalAlignment="Center"

                                          VerticalAlignment="Center"/>

                </Grid>

            </ControlTemplate>

        </Setter.Value>

    </Setter>

</Style>

 

 

Esimesel pildil on tavaline nupp, teine pilt on pärast Template sättimist. Nagu dependency propertid ikka, siis nupu stiilis väärustatud asjad voolavad edasi ka seesmistele asjadele(tekstile näiteks). Kui meil on vajalik see, et ainult konkreetne nupp saab stiili, siis peame stiilile juurde lisama nime. Seda saab teha kasutades „x:Key=’nimi’“ süntaksi. Hiljem, kui tahame nupule konkreetset stiili külge panna, tuleb kasutada süntaksi „Style=’{StaticResource nimi]’“. Stiil võib loomult olla dünaamiline või staatiline. Dünaamiline stiil loodakse mällu ainult, siis kui seda reaalselt vaja on, samuti on see sünkroonis muudatustega, mis sellele stiilile tehakse. Staatiline samas loodakse kohe ning ta ei ole sünkroonis stiili muudatustega. Tehakse niiöelda „snapshot“ stiilist, ehk koopia, mida nupp kasutab.

Stiilide mõte on see, et Visuali tiim otsustab ära elemendid, mis peaksid minema ühe stiili alla. Seda sellepärast, et hiljem on meil hea muuta kõike elemente korraga, kasutades selleks ühte konkreetset stiili. Stiilid ei pea kehtima ühesugustele elementidele. Me võime tekitada üldise stiili, mis kehtib kõikidele elementidele ning selles stiilis võime muuta väärtusi. Stiil kehtib kõikide elementide kohta, neil elementidel, millel pole antud väärtusi, mis stiilis muudetakse, nendega ei juhtu midagi.

Hea tava on panna, kõik stiilid ühte faili, tavaliselt on selleks ResourceDictionarsi mingisugune fail, mis kehtib üle rakenduse erinevatele akentele korraga. Esiteks on sealt kergem leida asju ning neid muuta, teiseks on WPF’il kiirem stiile üles leida(st kompilleerimisaeg on parem). Mõnikord on vajalik stiilifail lahku lüüa, kui see läheb liiga pikaks ning manageeritamatuks.

Stiilid võivad üksteisest pärineda, see aitab paremini muudatusi sünkroonis hoida, kuid tihti ei ole seda mõistlik kasutada, kuna stiilide pärimine läheb väga kiirelt mittehallatavaks ning segaseks.

Videode mängimine(MediaElement)

Erinevates prorammeerimiskeeltes on videode mängimine erinev, aga WPF teeb selle äärmiselt lihtsaks. Microsoft on teinud wrapperi(„controli“) WindowsMediaPlayeri ümber. Me peame lihtsalt kirjutama ühe rea koodi ning me saame videot näidata. Et see töötaks, peab sul reaalselt olema installitud Windows Media Player versiooniga üle 9. See tähendab, et MediaElement mängib täpselt samasuguseid videosi nagu ka WMP. Kõige lahedam on siin see, et meil on täielik kontroll selle üle. Me saame:

• Video pilti pöörata erinevates suundades
• Näidata ainult konkreetset osa
• Suurendada/vähendada videot(zoomimine)
• Video positsiooni muutmine/mängimine/video pausile panek
• Video peale joonistamine
• Jpm

Mis on aga kõige hämmastavam, sa võid video panna ükskõik kuhu. WPF on saavutanud sellise tehnoloogia, et kõik elemendid töötavad üksteisega harmoonias. Saame teha 3D kuubiku, mis keerleb 3D maailmas, samal ajal võime ühele tahule panna mängima video. Üheski teises keeles ei saa seda nii lihtsalt teha.

MediaElemendil on ka halbu külgi, nimelt on ta 1:1’le sõltuvuses WMP’ga. Olgu siin mainitud, et kui WMP mängib mingit videot, siis mängib ka MediaElement. Tähendab, kui Windows media playerit pole sinu arvutis, siis see element ei tööta. Samuti peab WMP versioon olema üle 9, ja toetatud on platvormid alates XP’st, mis muidugi ei olegi nii halb, aga sul peab olema vähemalt XP SP3, muidu tekivad probleemid. Samuti peab su rakendus olema kompilleeritud x86 peale, sest WMP ise on ju 32-bitine. Aga see pole kõik, neid probleeme on hulgaliselt. Üheks teiseks tõsiseks probleemiks on see, et MediaElement ei suuda videot mängida, kui programmi aken on TEISEL monitoril(mitte peamonitoril – primary).  See probleem on väga absurdne ning esineb alati, aga paranduse kohta ei oska keegi midagi öelda.

Ka ei suuda MediaElement mängida videosi otse striimist või mälust, seega igasugune videode kaitsmine jääb ära, olgu siin mainitud, et mingisugune custom-lahenduse support on olemas ainult Silverlightil. Kui on vaja videosi kaitsta, siis soovitan vaadata ActiveX Windows media playeri komponenti. Seal on olemas tehnolooia DRM(Digital Rights Management), mis on Microsofti tehnoloogia millega saab krüpteeritud videosi otse kettalt mängida, juhul kui sul on selleks vajalik sertifikaat olemas. Olgu siin hoiatuseks, et ActiveX komponent on alati pealmine ja selle peale ei saa joonistada midagi.

MediaElement on ebaefektiivne, sageli ta ei suuda videot mängida korralikult ning inimesed on kurtnud selle üle, et see on halvasti implementeeritud. Alternatiivideks on olemas VLC wrapperid, mis töötavad PAREMINI, aga VLC ei tohi kasutada kommertsiaalses projektis, kuna ta on GPL litsentsi all.

 

Animatsioonid

WPFis on võimalus properteid animeerida. Animeerimine ei tähenda mitte midagi muud, kui, et automaatselt muutub muutuja väärtus üle aja. See kas ta muutub lineaarselt, aeglaselt->kiirenevalt vms, oleneb animatsiooni tüübist.

Kui tahame teha sellist asja, et nupule peale minnes hiirega, nupp suuremaks läheb kahekordselt(SUJUVALT!), siis see on väikese vaeva ning animatsioonidega tehtav. Animatsioonide ning triggerite peamine vahe on see, et animatsiooni tehakse üle aja SUJUVALT, aga trigger täidetakse nii kiirelt, kui võimalik. See muidugi tähendab seda, et iga animatsioon käivitatakse eraldi threadil, et UI kinni ei jookseks.

<Rectangle

Name=”MyRectangle”

Width=”100″

Height=”100″

Fill=”Blue”>

<Rectangle.Triggers>

 

<!– Animates the rectangle’s opacity. –>

<EventTrigger RoutedEvent=”Rectangle.Loaded”>

<BeginStoryboard>

<Storyboard>

<DoubleAnimation

Storyboard.TargetName=”MyRectangle”

Storyboard.TargetProperty=”Opacity”

From=”1.0″ To=”0″ Duration=”0:0:5″ />

</Storyboard>

</BeginStoryboard>

</EventTrigger>

</Rectangle.Triggers>

</Rectangle>

 

Lihtne näide sellest, kuidas me saame ristküliku läbipaistvust animeerida. Animeerimine algab ühest(täiesti nähtav) ning 5 sekundi jooksul läheb ta nulliks(täiesti läbinähtav). Animatsioonide juures on see hea, et neid saab kirjutada XAML’i otse. Me saame käivitada animatsioone erinevalt, esiteks on ’EventTrigger’ – nagu selles näites, mille abil saame animatsioonide käivitada siis kui mingi event(juhtum) toimub. Aga on ka teine võimalus, kui mõni property muutub, siis saame triggerite vahele pista animatsiooni.

Animatsioonidel on olemas ka „EasingMode“ property, selle abil saame muuta, kuidas muutuja muutub üle aja. Algselt muutub see lineaarselt, aga kui kasutame „EaseIn“, siis alguses muutub ta aeglaselt, isegi jääb seisma, või läheb negatiivseks, ning siis ühel hetkel hakkab järsult kasvama. Igal ’Easingul’ on oma effekt, oleneb olukorrast ning tavaliselt inimesed mängivad läbi variandid.

WebBrowser

Veebinavigeerimine programmis on tehtud lihtsaks. Selleks, et oma applikatsiooni saada veebinavigeerimisfunktsioon, on meil mitu võimalust. Kõige lihtsamaks võimaluseks on kasutada ActiveX IE wrapperit. See tähendab seda, et meie programmis on reaalne Internet Explorer „embedded“. Milline versioon täpsemalt, oleneb sellest, mis versioon meil endal installitud on. Siin tekibki väike probleem, nimelt IE versioonid käituvad erinevalt. Kui programmeerida lahendus, mis on sõltuvuses suuresti veebibrauserist ning spetsiifilise HTMLI&JavaScripti kuvamisest, tuleks väga ettevaatlikult programmeerida.

Kuna ennist mainisin juba, et veebibrauser on ActiveX, siis tähendab see meile seda, et ME ei saa kasutada selle peal WPFi operatsioone(nagu ntx pööramine/suurendamine). Kui sul on projekt, kus on vaja veebibrauserit näidata kahes samas kohas(nagu kopeerimine), siis läheb see väga raskeks. Kui tavalistel WPFi elementidel saab teisi elemente tagataustaks määrata, siis ActiveX puhul see nii ei ole.

Kuid baaslevelil, ta teeb oma tööd ning väikese vaevaga saab teha oma nägemuse järgi veebibrauseri. Kõigil inimestel, kes soovivad aga midagi tõsisemat ja rohkem WPFi sõbralikumat/paremini kohendatavat, siis võiks vaadata WPFi komponendi poole nimega „Awesomium“. Tegu on komponendia, mis on wrapper Chrome ümber(Chromer on vabavaraline tarkvara C++’s). Samas, Awesomiumi litsents maksab raha, kui on plaan seda programmiga koos müüa.

Miks on Awesomium hea? Ta kindlustab selle, et meie programm töötab igal arvutil samasuguselt, vahet pole, mis versioon meil brauserist on(mitte nagu IE puhul). Ja kuna ta on WPFI sõbralik, siis saab teda kasutada rohkem olukordades. Awesomium toetab HTML5’t, mis tähendab, et sellega saab väga võimsaid trikke teha. Integratsioon C# ning selle komponendi vahel on tihe. Me saame kutsuda JavaScripti funktsioone ning JavaScriptist saame kutsuda C# funktsioone ning objekte serialiseerida üle toru(JSON). Ka on olemas Awesomiumil Flash tugi, mis tähendab, et saame seal flash faile näidata. Kusjuures, flash tugi on tal alati, kuna ta kasutab integreeritud flashi(NPSWF.dll), isegi siis kui sul endal flashi installitud pole.

 

 

 

Kasutatud kirjandus

 

• WPF 4 UNLEASHED – Adam Nathan
• Introduction to WPF – http://msdn.microsoft.com/en-us/library/aa970268.aspx
• WPFIntroduction – http://www.wpftutorial.net/WPFIntroduction.html
• Animations – http://msdn.microsoft.com/en-us/library/ms752312.aspx
• Dependency properties – http://msdn.microsoft.com/en-us/library/ms752914.aspx