Czytam na forum i w różnych kursach że przechodząc z Windows Forms na WPF nalezy całkowicie zmienic myślenie. Problem w tym ze nigdzie nie ma tej informacji jak się przestawic, co zmienić. Mógłby ktoś wyjaśnić jak to ma wyglądać?
0
0
Wszystko sprowadza się do przeklinania i szczerej nienawiści do tego kto wymyślił że pisanie kodu w xaml'u i edytorze testu jest lepsze niż korzystanie z IDE, musisz nauczyć wzdrygać się na samą ten xaml' został wymyślony jako tak bardzo generycznie że możesz wszystko ale visual sobie za nic z tym nie radzi i błędy dostajesz w dopiero runtime, bo tak. Konieczność odpalania za każdym razem całej przyprawionej aplikacji tylko po to by dowiedzieć się że gdzieś jest coś nie tak(Kody błędów jeśli już są to są równie generyczne i znaczą wszystko i nic) aż prosi się o prostytutkę. Ale to nie jest jeszcze takie złe istnieje taki fearure validacja przez symulacje VS symuluje to co napisałeś i zwraca pierwszy bład z runtime'a jako bład kompilacji... oczywiście bez callstack'a, bo przecież null reference to wystaczający opis problemu.. Oczywiście jak przystało na WPF czasami przez to serio nie można skompilować projektu(pomimo tego zeskompilował sie na tyle by sprawdzić run time oO), czasami można ale dopiero za 3 razem ale reguły da rade odpalić appke tylko po to by dostać nulla jak człowiek.
Rename nazw między na linii C#/WPF dla nie których przypadków działa a dla nie których nie Try&Curse development, smaczku dodaje fakt że jak VS nie poradził sobie z rename to pewnie też nie poradzi sobie z wykryciem błędu i runtime albo się wywali albo będzie działać źle... Dlaczego komunikacja na lini WPF C# jest w ogóle ważna? a no dlatego że istnieje taki świetny feature jak binding, i zamiast pisać miliony linii kodu uppadetu kontrolek i mieć niezły ból głowy. Wystarczy tylko viewmodel spiąć go w przyprawionym xaml'u i wszystko dzieje się automatycznie, jak działa to działa naprawdę super. No prawie automatycznie bo jeśli robisz coś bardziej skomplikowanego niż formularz do wyboru imienia, to musisz za każdym razem zaimplementować Inotifypropertychanged co wymaga copy pasty ze stackoverflow a potem tylko przerobienie WYSZYTKICH property na ich pełną implementacje i dodanie tam onPropertyChange(). Równie fascynujące co mycie naczyń. Jak już to zrobisz to musisz zrobić to drugi raz w xaml'u tylko bez IDE :). Można teoretycznie podpiąć IDE do view modelu i czasami nawet to działa a czasami łapie buga i każe Ci kopulować ze sobą,Pray&hope development + Try&Curse development.
A najbardziej w prostytuującą rzeczą jest że wszystko działa niby podobnie ale tak na prawdę za każdym razem inaczej, a jak to musisz wyczytać chyba z gwiazd bo przez 10 lat istnienia tej technologii nikomu nie udało się napisać ksiażki/poradnika w stylu z czym jeść. No może poza stroną 2.000 thing about wpf, ale to tylko pobieżna lista dwóch tysięcy osobnych featurów
2
Trzeba po prostu wziąć jakąś książkę o WPF i przeczytać, bo tu wyklikiwanie UI bez znajomości xamla kończy się tym co powyżej, nienawiścią do całego świata :D.
0
@neves: i wziąć na warsztat jakiś framework MVVM np. Prism czy MVVM Light. Bez tego czeka nas niepotrzebna rzeźba tego co zostało dawno już napisane plus wręcz nieocenione messengery.
Pisanie bez tego to dokładanie sobie nawet do 60% dodatkowych, niepotrzebnych prac.