Czy kiedykolwiek zdarzyło się Wam spotkać z aplikacją, która podczas przetwarzania jakiś bardziej złożonych i czasochłonnych operacji, zamrażała swoje okno w sposób, który skutecznie blokował Waszą pracę?

Czy nie zdarzało się Wam również w takich sytuacjach ujrzeć pełny optymizmu napis Brak odpowiedzi?

Podejrzewam że każdy z Was, przynajmniej raz spotkał się z taką sytuacją. Być może część z Was przeklinała system operacyjny, choć w istocie to nie była do końca jego zasługa. Bardziej winny w takiej sytuacji był niestety programista, który z niewiedzy/braku czasu/cwaniactwa (niepotrzebne skreślić) nie zaimplementował wielowątkowości w swojej aplikacji.

Być może wielu programistów, boi się po prostu tego zagadnienia, choć w gruncie rzeczy jest ono całkiem proste w implementacji. W przypadku gdy korzystamy z aplikacji napisanych w WPF/Silverlight i chcemy skorzystać z dodatkowego wątku, który nie będzie blokować naszego interfejsu UI, to w takim celu, świetnie sprawdzi się tytułowy BackgroundWorker.

Za każdym razem, kiedy kończymy tworzenie jakiejś nowej aplikacji, bądź też wypuszczamy aktualizację dla programu dobrze znanego na rynku, zachodzi konieczność utworzenia, bądź też zaktualizowania instalatora dla tejże aplikacji. Oczywiście możemy pliki wykonywalne aplikacji wraz z zasobami dostarczyć naszym użytkownikom np. w postaci skompresowanego archiwum, jednak często jest to rozwiązanie nie do końca elastyczne i wygodne - wymaga choćby użycia dodatkowej aplikacji obsługującej kompresję plików.

Dlatego też warto posiąść wiedzę o tym i jak tworzyć własny instalator. Przy użyciu Visual Studio i projektu Setup Wizard jest to stosunkowo proste zadanie.

Jakiś czas temu, we wpisie Tworzenie aplikacji wielojęzycznych z C# i ASP.NET w Visual Studio opisywałem jak stworzyć aplikację, która będzie przystosowana do obsługi wielu języków i wykorzystywać będzie do realizacji tego celu mechanizm zasobów udostępniony w platformie .Net.

Wpis ten, nie opisywał jednak zastosowanie tego mechanizmu, dla aplikacji napisanych pod kątem frameworka WPF, który korzysta z języka XAML. Dlatego też dziś, w ramach kolejnego wpisu z cyklu WPF Tutorial, chciałbym nadrobić braki w tamtym opisie.

W poprzedniej części tutoriala, poświęconej tworzeniu własnych kontrolek użytkownika, wspomniałem co nieco o zasobach i stylach, które możemy umieścić w pliku dodatkowym, bądź też w aktualnie przetwarzanym dokumencie. Dziś chciałbym rozszerzyć trochę temat i pokazać bardziej praktyczne wykorzystanie zasobów. Dowiecie się między innymi o tym jak:

• Utworzyć zasoby lokalne dla wybranego okna/elementu
• Utworzyć zasoby globalne dla całej aplikacji
• Jak tworzyć powtarzalne elementy jako zasoby (np. menu kontekstowe) i wykorzystać je w praktyce

Wykorzystywanie atrybutów w C#, jest często marginalizowane, a nawet wręcz pomijane przez programistów tego języka. Jak pokazuje życie, mogą one być całkiem przydatne np. w serializacji obiektów do XMLa. Mogą one się przydać, również w naszych własnych programach. Użycie atrybutów, może spowodować, że napisany przez nas kod będzie bardziej elastyczny i skalowalny, a chyba to się liczy, prawda;)?

W dzisiejszym wpisie, chciałbym zatem Wam pokazać, jak w banalny sposób można utworzyć własną klasę atrybutu i jak wykorzystać ją w praktyce.

Jeden z czynników, który warunkuje dobrego programistę, to umiejętność tworzenia elastycznego i niepowtarzalnego kodu. Jeśli jakiś element naszego kodu jest powtarzalny, bądź schematyczny, to z pewnością warto się zastanowić nad napisaniem metody, która zawrze ten kod i będzie mogła być wykorzystana wielokrotnie. Napisana przez nas aplikacja stanie się bardziej przejrzysta i z pewnością zmaleje również ryzyko popełnienia błędu, a wszelkie zmiany będzie można wykonać w jednym miejscu.

Podobnie sprawa wygląda z GUI. Wielokrotnie tworząc złożone interfejsy użytkownika, tworzymy określoną, powtarzalna kombinację kontrolek, bądź też kontrolkę o specjalnych właściwościach, którą również wykorzystujemy wielokrotnie. Zbrodnią byłoby by w tym przypadku, powtarzać ten sam kod wielokrotnie. Nie chodzi już tu w tym przypadku tylko o zmysł gustu i dobrego smaku w programowaniu, ale o przyszłą elastyczność, bo GUI bywa szczególnie zmienne, a zmiana w jednym miejscu jest stokroć tańsza, aniżeli zmiana w niezliczonej liczbie miejsc w całej aplikacji. Jaki morał, z tego wyjątkowo długiego wstępu? A no taki, że warto zainteresować się tworzeniem własnych kontrolek, czyli w WPFie tzw. kontrolek użytkownika (z ang. UserControl).

Od ostatniej części tutoriala WPF, poświęconej tworzeniu prostego kalkulatora minęło już kilka tygodni, więc czas najwyższy na nową część. Dziś zajmiemy się zagadnieniem niezwykle ważnym z punktu widzenia wykorzystania własnych danych w połączeniu z interfejsem graficznym. Mowa oczywiście o bindowaniu, czyli wiązaniu danych wyświetlanych w kontrolkach, a pochodzących np. z naszych własnych obiektów, właściwości, bazy danych etc.

Witajcie w trzeciej części tutoriala do WPF. W dwóch poprzednich wpisach (WPF Tutorial - wprowadzenie oraz WPF Tutorial - obsługa kontrolek), powiedzieliśmy sobie m.in o:

• WPFie ogółem
• Języku znaczników XAML
• Podstawowych właściwościach WPF
• Kontrolkach

Ponieważ wiemy już całkiem sporo, to czas dowiedzieć się, czy z tych informacji można zrobić jakiś sensowny użytek, np. budując prosty, tytułowy kalkulator:) Jeśli zatem chcecie wykorzystać zgromadzoną dotychczas wiedzę, do zbudowania czegoś praktycznego, to zapraszam do dalszej części wpisu:)

W poprzedniej i zarazem pierwszej części tutoriala do WPF, powiedzieliśmy sobie co nieco na temat samego WPF, zawartego w nim języka XAML oraz menadżerów układów. Dziś przyszła kolej na kontrolki, bez których w GUI, nie było prawdopodobnie by niczego. Co należy rozumieć jako kontrolkę? Są to wszystkie buttony, gridy, listy, comboboxy itp. itd. Każda z kontrolek, posiada pewien wspólny zestaw właściwości, które bierze się z reguł dziedziczenia zawartych w WPFie (patrz akapit o drzewach). Oprócz tego, kontrolki cechują się własnymi właściwościami i zdarzeniami, uzależnionymi od funkcjonalności przez siebie dostarczanych, które determinują jej wygląd oraz zachowanie.

Pewną niespodzianką może być również fakt, że menadżery układów, które przedstawiłem w pierwszej części, również określane są mianem kontrolek i jak już wspomniałem wcześniej, stanowią one integralną praktycznie każdego interfejsu użytkownika.

Do grona rzeczy, które wyróżniają aplikację, już na pierwszy rzut oka, najczęściej z pewnością możemy zaliczyć jej GUI, czyli innymi słowy wartstwę prezentacji. W .Necie, praktycznie od zawsze, GUI tworzyło się za pomocą dość wygodnych Windows Forms, które za pomocą metody Drag and Drop (Przeciągnij i upuść) pozwalały na szybkie tworzenie wizualnego obszaru naszej aplikacji, często bez napisania nawet jednej linijki kodu. Istotą takiego podejścia, było użycie absolutnego pozycjonowania elementów, względem całej formatki. Tymczasem w innych językach programowania, np. w Javie od zawsze istniały różnego rodzaju menadżery układów, które pozwalały np. na grupowanie elementów pionowo, poziomo, czy np. w układach tabelarycznych.

Tytułowy WPF (Framework, który został wprowadzony w .Net 3.0) to właśnie taki trochę ukłon, w stronę podejścia zaserwowanego w Javie. Znika całkowicie pozycjonowanie absolutne, a na znaczeniu zyskują wszelakie menadżery układów oraz właściwości typu Padding i Margin. Znika również plik, w którym Visual Studio generowało wszystkie właściwości układu wizualnego, czyli znany designer. Co dostajemy w zamian? Nowe podejście, które wykorzystuje do projektowania GUI język XAML (Microsoftowa pochodna XML), bardziej przypomina tworzenie stron internetowych, niż aplikacji okienkowych znanych z Windows Forms. Tak więc zacznijmy od początku;)