dotNETportal.cz

Dobrý den, mohl by jste mi někdo napsat jaké jsou vyhody WPF oproti WinForms? A proč na ně přejít? Děkuji.

Výhody:

- Veškerá grafika nezávislá na DPI

- Propracovaný data binding

- Rozsáhlá podpora pro různé animace a multimediální obsah

Nevýhody:

- Nespolupracuje s Windows API tak dobře jako Windows Forms

- Jiná technologie než Windows Forms - nutné se vše naučit znovu

- Chybí některé základní komponenty co jsou ve Windows Forms

Pokud aplikace není zaměřená na nějaký graficky intenzivní obsah, potom nemá cenu WPF používat.

Díky za informace, začal jsem se jej učit a celkem se mi líbí, je pravda, že některé užitečné komponenty tam chybí, třeba ColorPicker... Líbí se mi tam ty animace a lepší práce s grafikou všeobecně. Myslím si, že se to dá použít i na obyčejnější aplikace, ale je to tak trochu ztráta času, ale já právě tu grafiku a animace chci, takže zatim to vypadá skvělě :-)

PS: Chtěl jsem se ještě zeptat, zda má cenu se doučovat Silverlight(Ano je to sice webové WPF, ale přece jen trochu odlišné je, spíše bych řekl omezenější), když Microsoft dal jasně najevo, že bude upřednostňovat HTML5(Osobně mi nepříjde příliš chytré toto udělat, zvláště u technologie, která je ještě ve vývoji, ale to už je jejich věc).

Pokud se chcete v budoucnu zabývat webovými aplikacemi, pak rozhodně HTML5. Udělat co? Budoucnost je rozhodně v HTML5, ne v Silverlightu, Flashi nebo podobných hybridech mezi desktopovou a webovou aplikací.

Tak to je my jasné, HTML 5 také umim docela dobře, nyní se učím jeho nové JS API. Asi máte pravdu Silverlight bych použil na webu asi jen v případě, že by se jednalo o nějakou opravdu obtížnou aplikaci, kde by ani HTML 5 nestačilo. Díky za odpovědi ;)

Pokud aplikace není zaměřená na nějaký graficky intenzivní obsah, potom nemá cenu WPF používat.

Čemu říkáte graficky intenzivní? To, že chcete mít tlačítko v řádku gridu, obrázek v rozbalovacím seznamu přece není nic neobvyklého.

Navíc bych doplnil, že WPF má výrazně lepší layoutovací systém.

Graficky intenzivním obsahem myslím právě všelijaké animace, přechody a podobné Flash-like hovadiny, pro které je WPF primárně určeno a které se v běžných aplikacích absolutně nevyužijí. Klasický příklad využití těchto zbytečností může být nějaký mediální interaktivní kiosek.

Tlačítko v gridu nebo obrázek v seznamu jde bez problémů udělat ve Windows Forms a právě proto je zbytečné k tomu používat WPF.

Layoutovací systém - až na to zmiňované DPI a hardwarovou akceleraci vykreslování, která je při vykreslování běžných ovládacích prvků k ničemu, má Windows Forms rovnocenné možnosti.

No, přepisovat si OwnerDraw u listboxu sice možné je, ale je to daleko komplikovanější než napsat jednoduchou šablonu ve WPF, abyste v ListBoxu mohl mít co chcete.

Už kvůli bindingu bych šel do WFP. Layoutování ve WPF je taky trochu silnější.

Volit WPF jenom kvůli jednoduchému data bindingu je holý nesmysl. Pro volbu Windows Forms nebo WPF je potřeba zvážit všechny faktory aplikace, nejhorší je bez rozmyslu zvolit něco jenom protože to je moderní.

Já osobně WPF oťukávám více jak 3 roky a "do produkce" jsem ji zvolil až téměř před rokem. Od té doby jsem WinForms na žádný nový projekt nepotřeboval.

No však to taky nikde netvrdím, že se má používat, protože je moderní.

Spoustu z těch základních komponent najdete na Codeplexu jako WPFToolkit.

Díky, to už jsem si také stáhnul a je tam opravdu vše :-)

NotifyIcon ani BackgroundWorker, nebo jeho ekvivalenty v tom nejsou.

Příklady aplikací, kde se WPF hodí a kde je zcela zbytečné:

Windows Presentation Foundation

- Webový prohlížeč

- Kancelářský software (textový editor)

- Program pro úpravu obrázků nebo videa

- Program pro vizualizaci nějakých dat

- CAD/CAM software

Windows Forms

- Souborový manažer

- Stahovací program

- Vypalovací program

- Nástroj pro správu nebo údržbu systému

- Vývojářský nástroj

To je věc názoru a zkušeností. WPF není grafická úchylka, ale také systém na zcela běžné aplikace. Lze v něm psát mnohem pohodlněji, než ve WinForms. Existuje spousty nových událostí a vlastností, které musíte jinak různě ve WinForms hackovat.

Problém je, že téměř všechna dema na internetu ukazují ve WPF jen nesmyslné eye-candy efekty.

Proto si myslím, že všechny uvedené příklady, na které chcete využít WinForms by se dali mnohem pohodlněji napsat ve WPF.

A naopak například CAD/CAM software si vyžaduje rychlejší vykreslování, kdy se WPF nehodí.

Jako příklad může být grid. Psal jsem pokročilé gridy ve WPF i WinForms. Ve WinForms to bylo manuální vykreslování a různé hacky a stejně bylo přidání čehokoliv ne úplně běžného problém. U WPF byla celá práce logičtější a pozdější úpravy jsou výrazně jednodušší.

Myslím si, že je to částečně způsobené i tím, že WPF je výrazně modernější technologie, která se i poučila z chyb WinForms, doplnila a zjednodušila některé věci. Je pravda, že je možná trochu zbytečné psát XAML pro jednoduchou aplikace, ale zase to vývojáře vede k tomu, aby psali a ne dělali formuláře metodou Drag 'n' Drop jako to spousta lidí dělá u WinForms(i když je to možné i ve WPF, ale přece jenom je tam ten XAML víc na očích a donutí to víc lidí se ho naučit), máte tak mnohem větší kontrolu nad tím, co aplikace dělá, ale to už je zase věc osobního názoru, každopádně díky za všechny odpovědi, jdu do WPF, ten Data Binding tam je opravdu hodně dobře propracovaní.

Právě ten vizuální návrh UI, který je ve WPF k ničemu je velmi silná stránka Windows Forms.

Pro vás klidně může být k ničemu. A já váš názor respektuji. Stejně jako pro mě je k ničemu například WF, protože ho nepotřebuji a neumím. To ale neznamená, že budu tvrdit, že je to technologie k ničemu.

Pro mě je ale způsob návrhu pomocí XAMLu mnohem příjemnější a dovoluje mi lépe pozicovat a nastavovat vizuální vlastnosti, jako jsou šablony dat, komplexní binding a podobně. Chvíli mi trvalo, než jsem si zvyknul, ale nyní jsem schopen ve WPF navrhovat nepoměrně rychleji, než ve WinForms.

Vám připadá bastlení XAML kódu pro nastavení primitivních věcí rychlejší, než vizuální nastavení vlastností a rozvržení ovládacích prvků rovněž vizuálně pomocí TableLayoutPanelu? Pokud ano, tak to je právě tím jak jste ovlivněn webovými aplikacemi, kde to ani jinak rozumně dělat nejde (HTML, kterým bylo WPF inspirováno víc než nezdravě). Já netvrdím že je WPF k ničemu, pouze to, že se na většinu desktopových aplikací nehodí.

Já aplikace nebastlím.

Pokud potřebuji nastavit primitivní věci, udělám to přes designér. Obecně jsem ale rychleji schopen navrhovat vizuální formuláře v XAMLu, než klikátky.

Tak to tedy rozhodně nedaly. Příkladem může být právě ten souborový manažer, kde pro zobrazení ikon souborů lze ve Windows Forms použít jednoduché Windows API, které ikony namapuje přímo do ImageListu a ve WPF by se to muselo dělat bůchvíjak složitě. WPF dále nemá například takovou základní věc jako NotifyIcon nebo BackgroundWorker. Váš úsudek ohledně použití WPF je příliš ovlivněn webovými aplikacemi, pro většinu obyčejných desktopových aplikací se prostě nehodí. A takové věci jako například naprosto katastrofální podpora lokalizace ve WPF ani nezmiňuji.

Je vidět, že WPF nepoužíváte nebo tolik neznáte. Poslední rok a půl jej aktivně využívám. Předtím jsem několik let aktivně využíval WinForms. Formulářové aplikace dělám mnohem častěji, než weby. Ve WinForms i WPF jsem už napsal několik velkých aplikací, které se musejí dlouhodoběji udržovat.

Pokud chces zobrazit ikonky u seznamu, předěláte šablonu zobrazení dat tak, že do ní připíšete jeden obrázek. Záležitost na 4 řádky XAMLu jako vlastnost u listboxu nebo jako globální šablona. Žádné složitosti. O cachování obrázků se stará samo WPF. ImageList zde kvůli tomu není potřeba.

BackgroundWorker můžete zcela volně využít ve WPF. Není tedy nijak vázán Windows Forms.

Ano, NotifyIcon přímo pro WPF neexistuje. Použít ale můžete komponentu z Windows Forms. Navíc ale existují WPF komponenty zdarma, které využívám, které toto nahrazují a mají nepoměrně více možností než NotifyIcon.

pro většinu obyčejných desktopových aplikací se prostě nehodí - zatím jsem neslyšel jediný pádný argument, proč by se WPF nehodilo. Jistě, není to dokonalá platforma. Ale rozhodně je mnohem dál, než WinForms. Jediné zásadní proti je to, že naučit se WPF je složitější, než WinForms. V objemu možností je to ale pochopitelné.

S těmi ikonkami to tak jednoduché jak si myslíte není. Já mám na mysli automatické přiřazení odpovídající ikony určitému typu souboru definovanému v systému, ne žádné primitivní přiřazování obrázků položkám. Já jsem zase neslyšel jediný pádný argument, proč by se WPF používat mělo, obzvlášť v uvedených typech aplikací.

Debatu bych uzavřel s tím, že na něco se více hodí Windows Forms a na něco zase WPF a rozhodně není na místě za každou cenu používat to nebo ono.

Vy prostě neustále omíláte jednu a tu samou hloupost, nemá cenu vám vysvětlovat, že nemáte pravdu.

Co se týče ikonek, tak to tak jednoduše a efektivně pomocí Windows API ve WPF prostě neuděláte, protože WPF nemá ImageList, který je nutně potřeba. A podobných "systémových" věcí na které WPF nestačí by se dalo nalézt více.

Na zjištění ikony pro soubor dle cesty ImageList nepotřebujete - je to volání jedné WinAPI funkce a jediné, co je potřeba, je hlídat korektní Dispose.

Použít ImageList nutné je, pokud chcete, aby se automaticky přiřadily oba formáty ikony (16x16, 32x32) nutné pro přepínání mezi zobrazením Details nebo LargeIcon, navíc již jednou načtené ikony zůstávají nakešované v ImageListu což se taky hodí.

To můžu říct i o vás. Ale o tom, že vy tu nediskutujete, ale prosazujete za každou cenu svůj názor a hlavně svoje důvody, které většinou sedí přesně jen na typy aplikací, které jste psal, jsem se tu nejen já přesvědčil už mnohokrát.

A tvrdit mi tu, že argument pro používání WinForms je intergrovaný ImageList je, nezlobte se na mě, ale úplně mimo - bazírování na detailech. Ikony souborů jsem zobrazoval velmi pohodlně komponentou i ve WPF, kterou jsem napsal během 15ti minut. Tak mi tu netvrďte, že je to nějaký problém. Je to jen implementační drobnost, kde náhodou WinForms mají komponentu připravenou a WPF ne. Existují stovky situací, kde napsat nějakou funkci do souborového manageru ve WPF bude jednodušší.

To samé lze říct i opačně - na typy aplikací, které jste psal vy se více hodí WPF a proto se ho za každou cenu snažíte prosazovat.

ImageList že je argument pro používání Windows Forms? To jste vyhrabal kde? Ten ImageList jsem použil pouze pro demonstraci toho načítání ikon. Možná vám to připadá jako bazírování na detailech, ale ve výsledku to ovlivní vzhled UI a to je velmi podstatné pro uživatele. Ano, stáhnout někde již hotové řešení ve WPF je jistě jednoduché. Napište alespoň jednu z těch stovek věcí, ve které by bylo jednodušší použít WPF. Vsadím se, že nic jiného než jednoduchý data binding nebudete schopen vymyslet.

Neříkám, že se používat ikonky nemají, ale že to není překážka napsat do WPF.

Například:

- RoutedEvents (event preview) - logičtější a snadnější způsob jak zpracovávat události vnořených elementů u prvků, které se skládají z více jiných prvků - snadnější psaní komponent - například kompozice komponenty pro zobrazování složek a souborů

- Focus manager - možnost uzpůsobit si způsob chování focusu - přesná kontrola, jak se chová u komplexních aplikací focus, zamezení posunu focusu u komponent, které tlačítka změn focusu využívájí jinak - například zobrazení stromu adresářů, přepínání mezi panely

- Stylování - možnost stylovat komponent - nejen velikost textů a fonty, ale kompletní změna vzhledu koponent - například doplnění dalších možností do existujících komponent - například vzhled seznamu souborů, bez nutnosti vlastních komponent (pokud to nebude potřeba a půjde jen o jiný způsob zobrazení dat), nastavování vzhledu aplikace (skin)

- Attached properties - možnost definovat chování elementů - například přidat vlastní dockování (pokud je potřeba), lokalizace, napojení na vlastní systém událostí, reakce na změny stavů (zpracovává se událost, není možné pracovat s komponentou) a mnoho dalších využití - například vazba komponent na jednotlivé soubory - snažší přístup při bindingu

- Dependency Property - nejen zobrazení dat z modelu, ale také předávání kontextu, custom reakce na stav aplikace, není potřeba manuálně notifikovat - například historie, seznam adresářů

- Asynchronní binding, custom binding - lazy execution náročných operací - například náhledy souborů, ikonky aplikací

- Dispatcher - asynchronní operace lze lépe plánovat, řešit prioritu a návaznosti - například načítání podadresářů

To je všechno hezká teorie, ale zhodnotit to lze jedině prakticky u hotové aplikace, která má tyto věci implementovány. Hodnotit je potřeba především z pohledu uživatele, ne z pohledu vývojáře.

Naopak, hodnotit je potřeba z hlediska vývojáře a ne uživatele. Uživatel neví co je to win forms nebo WPF a taky není jediný důvod, proč by ho to mělo zajímat.

Pan Jecha Vám tu dal řadu hodně dobrých argumentů, proč používat WPF, ale vy to prostě už jen z principu nepřiznáte a budete se snažit kličkovat. Žádná novinka, všichni to tu už znají...

Vy absolutně nechápete co jsem napsal. Hodnotit aplikaci je vždy potřeba z pohledu uživatele a to právě proto, že technologická stránka věci je mu zcela lhostejná a zajímá ho pouze funkčnost. Jinak řečeno co je mu do toho, zda je to ve WF nebo WPF, nebo zda WPF potenciálně umí milion dalších věcí, když to ve výsledku bude dělat to samé? Proberte se.

Pánové, vývoj aplikace se musí řešit z několika pohledů - neexistuje Jediný Správný Pohled.

1. Hledisko pro uživatele je samozřejmě důležité, zde bude mít WPF navrch v případě dotykových displejů nebo ve chvíli kdy uživatel (zákazník) bude chtít vlastní vzhledy - pro některé aplikace se to hodí, pro jiné ne.

2. Další hledisko je z vývojářského pohledu - vlastní vzhled se dá dělat i u WinForms, ale je s tím více prácě - některé věci jsou zase jednodušší ve WinForms než WPF.

3. Určitě je důležitý i pohled z hlediska nákladů na vývoj - WPF neumí tolik lidí jako WinForms, proto si programátoři prvaděpodobně řeknou o trochu víc. Na druhou stranu je potřeba zvážit, jestli je z hlediska nákladů levnější nechat ji vyvíjet ve WinForms nebo ve WPF - záleží případ od případu - udělat vlastní vzhled je levnější ve WPF, něco je zase levnější ve WinForms. Otázka je třeba dostupnost komponent třetích stran.

Já si dnes již nedovedu představit, že bych začínal nový projekt ve WinForms - minimálně 60% zákazníků chce vlastní vzhled aplikace.

Z hlediska nákladů na vývoj mám spočítáno, že i v případech, kdy jde o klasickou business aplikaci s nativním systémovým vzhledem, je vývoj ve WPF s použitím našeho vlastního MVVM frameworku levnější - lidí, kteří WPF nebo Silverlight umí, mám dost.

V nejhorším případě jsem na tom s WPF nákladově nastejno jako s WF, ale rozhodně WinForms nebudou levnější - je pravda, že neděláme malé projekty o 3 oknech, tam by asi byly.

Souhlasím, ovšem velmi mě překvapuje, že v segmentu business aplikací někdo požaduje přizpůsobování vzhledu aplikace (skinovatelnost, pokud myslíme to samé), to po mě ještě nikdy nikdo nechtěl.

Co do rozsahu projektů tak ani já nedělám aplikace o pěti oknech a pěti tisících řádcích (TorrentControl je vyjímka, kterou dělám pro zábavu ve volném čase) a ještě jsem nenarazil na pádný důvod použití WPF místo Windows Forms.

Proto se znovu vracím ke svému původnímu tvrzení, že na něco se lépe hodí Windows Forms, na něco WPF a používat za každou cenu jedno nebo druhé je nesmysl.

Ještě bych poznamenal, že vytvářím rovněž aplikace pro mobilní zařízení, kde WPF chybí úplně a zde bych ho naopak uvítal právě kvůli dotykovému ovládání a snadnému přizpůsobování ovládacích prvků.

Po mě tohle chtěli i v business aplikací, jelikož je klient chce přeprodávat a brandovat svým dalším zákazníkům ve firemních barvách - chtěli měnit barvy pozadí, vzhled tlačítek, fonty atd.

Ideální mi to přišlo ve chvíli, kdy si zákazník dodatečně vymyslel, že kvůli dotykovým displejům potřebuje možnost v nastavení aplikace zapnout větší písmo - díky chytrému WPF layoutu bez absolutního pozicování se prostě jen změní FontSize na formuláři a protože všechny rozměry čehokoliv jsou určeny podle velikosti obsahu, byla to hračka.

A v okamžiku, kdy si vymysleli 3D animaci, do které se vkládají reálná data z aplikace, se WPF taky hodilo - je to pár řádků XAMLu místo patlání se s DirectX.

A věřím tomu, že polovina zákazníků, kteří tohle nechtěli, to za čas chtít budou - ve WPF se to udělá dodatečně taky snadno.

Na druhou stranu uznávám, že nabídka komponent třetích stran pro WinForms je širší a i ty vestavěné mají víc možností.

Jistě, hledisek je spousta. Původně se tazatel chtěl dozvědět, jakou technologii se začít učit. Snažil jsem se uvést argumenty, proč z technologického hlediska používat WPF. Je úplně jasné, že to není jediný pohled. Ani nevím, že by někdo trvdil opak.

Když už jsi ale nakousnul ostatní stránky:

Věřím, že i ostatní pohledy na věc budou nahrávat WPF - alespoň v případě projektů, které jsem řešil nahrávali téměř vždy. Už například nevidím důvod, proč používat WinForms technologii i na jednoduché aplikace. Nevidím v tom prostě smsysl. WinForms mi čas neušetří a s WPF zákazník je spokojenější (protože lze plnit jejich přání, které ve WinForms sice realizovat jdou, ale mnohdy mnohem složitěji) a projekt se mi lépe udržuje.

A co se týká nacenění vývoje UI, tak tady s WPF dokážu udělat nabídku lepší, než u WinForms. A obecně čím složitější aplikace, tím větší rozdíl.

Pár zásadních nevýhod, kvůli kterým bych WPF nepoužil, dokážu vidět v případech, kdy by se jednalo o velmi starý hardware a je potřeba hodně šetřit na výkonu. Ačkoliv to se mi nestalo už dlouho. Druhou nevýhodou je komplexnější a složitější přístup, který může v určitých případech mást vývojáře, kteří WPF neznají. A třetím důvodem je předchozí zakoupení nebo vývoj komponent pro WinForms, které nechcete nebo nemůžete použít ve WPF.

Pokud se ale bude nový vývojář rozhodovat v čem vyvíjet, stojím si za názorem, že se dnes vyplatí vrhnout se do WPF.

Moc všem děkuji za odpověďi, stalo se to co jsem tak úplně nechtěl, trochu to tady rozjelo flame, ale co to už je jedno, začal jsem se učit WPF a zatim se mi zdá lepší, jediné co mi na něm vadilo, je, že tam v základy nebyli některé komponenty, které WF měli, ale to jsem vyřešil pomocí WPF Extended Toolkitu. A asi budu souhlasit s tim, že WPF je ještě v plenkách(oproti WF), ale řekl bych, že až dozraje, tak úplně vytlačí WF, je to prostě tak a na grafiku bude kladen stále větší důraz. Ještě jednou všem děkuji, a prosím už nikdo nepřilévejte do ohně :-)

Bezva Topic mnoho se zde vysvětlilo např jak říkal Ondřej o výhodách a nevíhodách je až dost výmluvné dík moc všem :-)

Já bych za sebe jen podotkl, že jsem chtěl zkusit WPF, ale narazil jsem na to, že spousta věcí se tam nedá nastavit ve vlastnostech, ale je to potřeba dělat programově v jazyce XAML, což znamená učit se další jazyk. Učit se dva jazyky se mi fakt nechce a připadá mi to kontraproduktivní. :)