Archief - .NET WPF vraag
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Tyfius
Legacy Member
Zonder verder in detail te treden. WPF gebruikt DirectX als renderen, dus je hebt meer mogelijkheden tot fancy toeters en bellen.
Daarnaast gebruikt WPF ook XAML als XML based taal om je GUI's op te bouwen. Die kan je dan net zoals een website stylen en themen naar je eigen keuze. Je kan dat natuurlijk ook allemaal vanuit code doen, maar XAML is echt wel de way to go. Wij kunnen dat zelfs opsplitsen. Onze graficus maakt de GUI's in Expression Blend, en wij moeten alleen nog de code behind doen.
Ik zou zeggen, lees http://www.wpftutorial.net/WPFIntroduction.html eens door. Daar ga je ongeveer op al je vragen wel ergens een antwoord vinden.
Daarnaast gebruikt WPF ook XAML als XML based taal om je GUI's op te bouwen. Die kan je dan net zoals een website stylen en themen naar je eigen keuze. Je kan dat natuurlijk ook allemaal vanuit code doen, maar XAML is echt wel de way to go. Wij kunnen dat zelfs opsplitsen. Onze graficus maakt de GUI's in Expression Blend, en wij moeten alleen nog de code behind doen.
Ik zou zeggen, lees http://www.wpftutorial.net/WPFIntroduction.html eens door. Daar ga je ongeveer op al je vragen wel ergens een antwoord vinden.
Moto
Legacy Member
Ge moet gewoon kijken naar wie uw GUI applicaties gaat gebruiken en welke PC-specs ze hebben, WPF gebruikt dus directx om te renderen en dat geeft idd de mogelijkheid om "fancy" dingen te renderen, als men een deftige GPU heeft, met een deftige directx driver.
Bv de klant waar ik werk hebben ze nog redelijk oude PC's zonder GPU, als ik daar een WPF applicatie gebruik zoals VS 2010, dan heb ik bij het door de code scrollen een CPU-verbruik van 100%, is dat goed en fancy, nee verre van
Doe ik dat thuis op men quad-core met directx11 kaart gaat dat veel beter (maar nog niet zo goed als VS 2008).
Verder gebruikt WPF ook XAML dat als nadeel heeft dat het compileren van die XAML veel trager is dan gewoon een winform scherm oproepen
Bv de klant waar ik werk hebben ze nog redelijk oude PC's zonder GPU, als ik daar een WPF applicatie gebruik zoals VS 2010, dan heb ik bij het door de code scrollen een CPU-verbruik van 100%, is dat goed en fancy, nee verre van
Doe ik dat thuis op men quad-core met directx11 kaart gaat dat veel beter (maar nog niet zo goed als VS 2008).
Verder gebruikt WPF ook XAML dat als nadeel heeft dat het compileren van die XAML veel trager is dan gewoon een winform scherm oproepen
Krueger
Legacy Member
@Tyfius: Ik denk niet echt dat directX de reden is dat WPF fancy bellen en toeters toelaat, gewoon hun nieuw grafisch model hoe controls zijn opgebouwd (templates) is hier de reden van. Dit heeft als gevolg dat je in wpf veel eenvoudiger controls kan aanpassen (vb, buttons backgrounds, listviews met foto's in,...) Verder haal je ook een voordeel in wpf tov. winforms in verband met snelheid als je Windows vista of windows7 gebruikt, aangezien je dan wddm gebruikt ipv de gdi.
@moto: ik snap je laatste zin niet echt. Hoe kan je een winforms scherm oproepen vergelijken met het compileren van xaml. Dat zijn toch 2 totaal verschillende dingen?
en @topic starter:
ik zou zeggen dat wpf vooral het voordeel heeft van:
- potentieel sneller te zijn zoals al gezegd
- je kan er veel mooiere dingen mee maken op kortere tijd dan winforms
- een betere scheiding van code en GUI
- invoering van bepaalde concepten die niet gekend zijn in winforms, maar zeker een meerwaarde zijn. Ik denk dan voorveeld aan commands, databinding, triggers, ...
- layout is veel beter voorzien dan in winforms + is in principe resolutie onafhankelijk
Wpf heeft echter dan wel weer het nadeel van een steile leercurve te hebben. Je kan er misschien wel rap iets mee maken. Maar als je echt wil werken volgens de wpf filosofie, dan ben je wel al een paar maanden verder.
@moto: ik snap je laatste zin niet echt. Hoe kan je een winforms scherm oproepen vergelijken met het compileren van xaml. Dat zijn toch 2 totaal verschillende dingen?
en @topic starter:
ik zou zeggen dat wpf vooral het voordeel heeft van:
- potentieel sneller te zijn zoals al gezegd
- je kan er veel mooiere dingen mee maken op kortere tijd dan winforms
- een betere scheiding van code en GUI
- invoering van bepaalde concepten die niet gekend zijn in winforms, maar zeker een meerwaarde zijn. Ik denk dan voorveeld aan commands, databinding, triggers, ...
- layout is veel beter voorzien dan in winforms + is in principe resolutie onafhankelijk
Wpf heeft echter dan wel weer het nadeel van een steile leercurve te hebben. Je kan er misschien wel rap iets mee maken. Maar als je echt wil werken volgens de wpf filosofie, dan ben je wel al een paar maanden verder.
Moto
Legacy Member
een scherm openen in een winforms app is sneller dan in een WPF app, door het comileren van die xaml
is daar ergens een bron van? dus dat het sneller is dan winforms op vista/windows7
Als uw gebruikers geen deftige pc's gaan hebben, gebruikt WPF dan NIET, voor een gebruiker maakt het nu echt geen BAL uit als het in winforms of WPF is gemaakt, zolang dat het maar snel is. als het echter een projectje is puur voor op uw CV-ke te zetten, gebruik dan wel WPF
btw lol @ niet gekend
Krueger
Legacy Member
Dat kan inderdaad goed zijn, maar normaalgezien is een 'cold start' wel al stukken verbeterd in .net 4.0 tov 3.5. Maar het zou me ook niet verbazen dat winforms nog steeds stukken sneller is. Om ff te muggeziften: Xaml wordt niet meer gecompileerd als je je programma runt. Als je je programma build wordt er BAML gegenereerd, dit is een tussenstap tussen XAML en en executable. Deze BAML moet wel nog verder gecompileerd worden.Moto zei:
Ik heb het uit twee verschillende boeken, maar ik heb het nog niet zelf getest eerlijk gezegd.
Da's zeker waar. Ik run op het werk altijd met een dual core en thuis met een i7 , dus veel snelheidslast heb ik niet
Wat bedoel je, en je quote ook nog dat laatste suk van mij, maar je wegt er niets bij?btw lol @ niet gekend
Moto
Legacy Member
Door MVVM I presume? tja winforms heeft MVC/MVP of ge kunt ook MVP-VM gaan
ook allemaal patterns om code van GUI te scheiden, uiteindelijk de reden om die scheiding te doen is voor unit-testing, en unit-testing heeft men opeens nodig tegenwoordig om iets deftigs op te leveren
Die concepten zaten ook al in winforms heh, ze waren niet verplicht of altijd zo goed uitgewerkt, maar uiteindelijk is het niet veel nieuws
resolutie onafhankelijk, daar heb ik dus een probleem mee, wou thuis een projectje doen in WPF 4.0 nu ze er eindelijk in geslaagd zijn om scherpe fonts te renderen maar ik vind nergens een mooie showcase app daarvan, dus een app in WPF met clear text-rendering zoals in VS 2010,
Cycloon
Legacy Member
Moto zei:
Eigenlijk heeft dat bitter weinig te maken met "iets deftig op te leveren". Code test je sowieso, dus kan je er beter voor zorgen dat die testen makkelijk reproduceerbaar zijn en bij voorkeur ook nog eens volledig automatisch verlopen. De dag dat je eens aan onderhoud van code mag beginnen zal je blij zijn als er unit tests zijn (of eens goed vloeken als ze ontbreken).
Moto
Legacy Member
Het gaat hier eigenlijk over het toepassen van MVVM alle code-behind trachten te elimineren om zo 100% code coverage met unit testing te verkrijgen.
alles in MVVM + Geen code behind = een hoop extra werk ( + praktisch onmogelijk reallife)
100% code coverage = een hele hoop extra werk
+ dan nog mocken van DB's en andere zaken
+ constant onderhoud van de unit-tests
Met de huidige focus op unit-testing, lijkt het wel alsof men tegenwoordig vergeet dat men ook andere zaken moet testen nl : consistency / usability / load / scalability / performance / ....
Ik verkies liever iets goed gedesigned zonder unit tests, dan 1 of andere boecht-app met unit tests
alles in MVVM + Geen code behind = een hoop extra werk ( + praktisch onmogelijk reallife)
100% code coverage = een hele hoop extra werk
+ dan nog mocken van DB's en andere zaken
+ constant onderhoud van de unit-tests
Met de huidige focus op unit-testing, lijkt het wel alsof men tegenwoordig vergeet dat men ook andere zaken moet testen nl : consistency / usability / load / scalability / performance / ....
Ik ga al eens blij zijn als ik eens code zie dat op zich al deftig geschreven is met een deftig DB model.
Ik verkies liever iets goed gedesigned zonder unit tests, dan 1 of andere boecht-app met unit tests
Gurdt
Legacy Member
Het is net dat unit testing ervoor zorgt dat de implementatie + onderhoud gemakkelijker zijn. Ik denk dat unit testing niet zo populair zou zijn, moest het ervoor zorgen dat de app een boecht-app wordt. Met andere woorden, het heeft wel degelijk zijn nut, ik volg Cycloon volledig.
Cycloon
Legacy Member
Moto zei:
Eerlijk gezegd onderhoud ik liever slecht geschreven code met unit testen dan goede code zonder. Als je code gaat aanpassen heb je zonder unit testen geen flauw idee of je ergens anders iets breekt. Je kan dan bij die slecht geschreven software nog steeds stukken herwerken, zolang de unit testen succesvol draaien ben je vrijwel zeker dat de software ook nog correct zal werken.
Krueger
Legacy Member
Erm, nee? Commands, databinding en triggers zitten helemaal niet in winforms. Je kan ze zelf programmeren, om tot een zelfde resultaat te komen. Maar als dat jouw idee is van al aanwezig zijn, dan heb je wel een bizarre kijk op frameworks.Moto zei:
Resolutie onafhankelijk zijn gaat wel een stuk verder dan het mooi renderen van text...
Moto
Legacy Member
zolang ge 100% code coverage hebt, wat meestal niet zo is, IRL
en dus geven de unit-tests gewoon een vals gevoel van zekerheid.
ok, het is een stapke hoger dan "het werkt want het compileert" maar toch, met slechte code weet ge gewoon dat ge de volledige app van voor tot achter zelf manueel moet testen.
Anyway denk niet dat ge al veel slecht geschreven code hebt gezien
WPF en WinForms zijn libraries, de concepten van databinding + events zitten in WinForms alleen niet zo goed uitgewerkt als in WPF, commands is gewoon het Command Design Pattern, wat er velen ook gebruiken in WinForms ook geen nieuw concept
Krueger
Legacy Member
Ok, dan had ik dus gelijk dat je een zeer rare kijk hebt op frameworks. Je kan iets soortgelijk programmeren in winforms, dus het is aanwezig in winfoms. Dan mochten ze van jou waarschijnlijk ook stoppen met de eerste versie van .net , daarmee kon je ook alles, je moest het er gewoon zelf insteken. Natuurlijk kan je alles al met oudere versies, maar dat is net de meerwaarde van nieuwe frameworks, de standaard ondersteuning van veelgebruikte praktijken. De invoering van LINQ was dan ok geen nieuw concept zeker volgens jou, want je kon ook al alles voordien.Moto zei:
En daar ging deze topic nog steeds over (niet over unit testing btw). Wat is het voordeel van wpf tov. winforms. En een van deze voordelen is dat daabinding, commands,... standaard is ingebakken in wpf, en NIET in winfroms.
Moto
Legacy Member
Unit tests worden meestal geschreven om het manueel testen te verminderen, onderhoud van een app met goede unit tests krijgt ook mijn voorkeur ze, duuuuuuuuh.
paar punten die ik wil duidelijk maken
- Het concept Unit testing is op zich goed
- Unit testing kost tijd
- Uw app designen (MVVM) met oog op meer coverage met unit testing kost nog meer tijd
- Wat gaat minder tijd krijgen??? meestal manueel testen
- Unit testing is niet belangrijker dan alle andere testen
- Deftig software design is nog steeds beter dan unit testing
@ Krueger, niet onnozel beginnen doen, databinding triggers en commands zijn geen nieuwe concepten die pas bij WPF zijn ingevoerd, dat is alles wat ik zeg.
en btw
Dat het tot WPF 4.0 heeft geduurd voordat men eindelijk text scherp kon renderen is een REGELRECHTE SCHANDE. maar dus verder op men vraag als ge een goede WPF showcase weet met scherpe text rendering, laat maar weten
Tyfius
Legacy Member
Wij hebben momenteel geen font problemen meer. In het begin waren er wel een aantal, voornamelijk omdat we ook heel veel verschillende tekst blokken op 1 scherm hadden en deze dan in borders staken die bepaalde glows en dergelijk hadden. Resultaat was blurry tekst, voornamelijk onderaan het scherm. Door daar mee rekening te houden en onze layout gestructureerd en proper op te bouwen hebben we dat eigenlijk kunnen oplossen.Moto zei:
Ik kan mij eigenlijk ook geen enkel scherm meer herinneren dat we het laatste jaar hebben opgebouwd waar we font problemen mee hebben, op eender welke resolutie.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.