Ten kod nie działa w FF:

Ten kod działa w FF:

Różnica? Self-closing tag script, użyty nieopatrznie w pierwszym przypadku powoduje totalne ogłupienie FF. Opera zachowuje się bez problemu.

Powiązane wpisy:

1. Show-hide JavaScript – proste podłączenie przy użyciu C#

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Pytanie to – w wersji teoretycznej – poruszane było nie tak dawno na devpytaniach. Jeśli możemy założyć, że konflikty będą występować rzadko lub jest to akceptowalne w konkretnym przypadku, który mamy zaprogramować, użycie optymistycznego blokowania jest dobrym i prostym wyborem.
Optimistic concurrency nie blokuje rekordu przy jego pobieraniu, natomiast przy zapisie dokonywane jest nadmiarowe sprawdzenie, czy dane w bazie są tożsame z danymi, które były podstawą naszych zmian.

Stanąłem przed problemem obsługi optimistic concurrency przy korzystaniu z Entity Framework 4.0. Po krótkiej lekturze „Entity Framework 4.0 Recipes – A problem-solution approach” okazało się, że EF wspiera Optimistic Concurrency. Wystarczy dodać do bazy danych kolumnę informującą o – mówiąc ogólnie – wersji obiektu. Najłatwiej będzie przeanalizować problem na bardzo prostym przykładzie (kod do pobrania na końcu artykułu).

Załóżmy, że mamy tabelę przechowującą informacje o klientach:

Zacznijmy od dodania kolumny Timestamp, która pomoże nam w obsłudze OCC.

Teraz możemy wygenerować nasz model w EF. Tutaj następuje kluczowy krok – oznaczenie kolumny Timestamp jako odpowiedzialnej za sprawdzanie wersji obiektu.
W kolumnie Timestamp w naszym modelu musimy zmienić dwie właściwości:

• StoreGeneratedPattern – na wartość computed. Podpowiadamy tutaj EF, że wartość tej kolumny nie będzie ustawiana przez nas a generowana za każdym razem gdy obiekt jest wstawiany lub aktualizowany.
• Concurrency Mode – na wartość fixed. Ustawienie to oznacza, że oryginalna wartość tej kolumny będzie dołączona do warunku WHERE przy modyfikacji danych. Są to właściwie dwa przypadku – kasowanie oraz aktualizacja. Warunek taki wyglądał więc będzie mniej więcej tak: update table set …. where id = @id AND fixedColumn = @fixedColumnOriginalValue

Po wykonaniu tych prostych modyfikacji możemy przetestować nasz model i jego zachowanie w przypadku wystąpienia konfliktu.
Prosty kod testowy, który:

• Pobiera dane klienta korzystając z jednego kontekstu EF, zmienia je ale nie utrwala z powrotem w bazie
• Pobiera dane tego samego klienta, zmienia je i od razu utrwala korzystając z innego kontekstu.
• Utrwala dane klienta z kroku pierwszego

Wynikiem działania tego kodu będzie rzucenie wyjątku w momencie wywołania ostatniej linii:

Entity Framework dzięki naszej kolumnie fixed typu timestamp wykrył, że nastąpiła modyfikacja obiektu między momentem pobrania go przez nas a chęcią wykonania zapisu. Wyjątku typu OptimisticConcurrencyException informuje nas o tym fakcie i pozwala obsłużyć tę sytuację. Wystarczy prosta modyfikacja ostatniej linii naszego kodu:

I problem optimistic concurrency rozwiązany.
Możemy również zaprząc do pomocy program Sql Server Profiler (nieoceniony przy pracy z Entity Framework) aby przekonać się, że wszystko wykonuje się dokładnie tak jak tego oczekiwaliśmy.

Tak wygląda pierwsza aktualizacja obiektu (ta nie powodująca wystąpienia wyjątku):

Tak natomiast ostatnia aktualizacja obiektu, czyli powodująca konflikt:

Jest to być może mało zauważalne, ale oba polecenia T-SQL jakie wygenerował dla nas EF modyfikują kolumnę Group różnymi wartościami („C” oraz „B”) jednocześnie wysyłając identyfikator rekordu (Id) oraz wartość kolumny Timestamp. Entity Framework sprawdza następnie ile rekordów zostało zmodyfikowanych poleceniem. Jeśli ta liczba wynosi zero – rzucany jest wspomniany wcześniej wyjątek.

Kod aplikacji testowej do pobrania: OptimisticConcurrencyDemo – VS 2010 Solution

Nie znaleziono powiązanych wpisów.

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Powiązane wpisy:

1. BugNET i TRAC – porównanie. Część I
2. Wielopoziomowa aplikacja – nauka przez przykład

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

System.Data.UpdateException: Wystąpił błąd podczas aktualizowania wpisów. Aby uzyskać szczegółowe informacje, zobacz wyjątek wewnętrzny. —> System.ArgumentException: Używana wersja programu SQL Server nie obsługuje typu danych ‘datetime2′.

ang: The version of SQL Server in use does not support datatype ‘datetime2

Najdziwniejsze było jednak to, że po przeskanowaniu całego pliku EDMX nigdzie nie stwierdziłem występowania typu „datetime2″ w mapowaniach. Typ „datetime2″ został dodany w MS SQL Server od wersji 2008. Problem okazał się dość trywialny – EDMX (czyli wszelkie mapowania i ustawienia) zostały wygenerowane dla tej właśnie bazy. Połączenie natomiast realizowane było z bazą MS SQL  Server 2005.

To naprowadziło mnie na przeszukanie pliku EDMX raz jeszcze – w zwykłym edytorze tekstowym, bez designera. Winowajcą okazała się linia:

a dokładniej atrybut ProviderManifestToken ustawiony na wartość 2008. Po krótkim googlowaniu dowiedziałem się, że gdy ProviderManifestToken jest ustawiony na 2008, Entity Framework domyślnie używa jako typu daty właśnie datetime2. Ręczna zmiana na „2005″, kompilacja i – wszystko działa.

Powiązane wpisy:

1. Entity Framework i optimistic concurrency

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Program do pobrania: tutaj

Dla ciekawskich, realizacja poszukiwania XPath realizowana jest następującym kodem:

Powiązane wpisy:

1. Show-hide JavaScript – proste podłączenie przy użyciu C#

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Jeśli będziemy wiedzieć czego użytkownik oczekuje, będziemy mogli zaproponować rozwiązanie spełniające te wymagania.

Poniżej opowieści:

1. Aplikacja ma wspomagać zarządzanie zadaniami rozdzielanymi dla użytkowników firmy.
2. Po wykonaniu zadania, przenoszone jest ono do „archiwum”, tak aby możliwy był podgląd zrealizowanych już zadań
3. Zadania mają prostą postać. Użytkownik zlecający zadanie może zdefiniować:
   • Temat
   • Treść
   • Priorytet (zwykły, wysoki, krytyczny)
   • Data wykonania (opcjonalna – nie zawsze jest określana)
   • Osoby, które przypisane są do realizacji danego zadania (jedna lub więcej)
4. Zadania mają statusy:
   • Aktualne
   • Zrealizowane (archiwalne)
   • Zakończone bez realizacji (archiwalne)
5. Użytkownik ma dostęp do listy swoich zadań. Widzi zarówno zadania przypisane do siebie jak i zadania przypisane przez siebie dla innych osób. Kolumny widoczne na liście, to:
   • Tytuł
   • Priorytet (w formie graficznej –ikona symbolizująca priorytet)
   • Opis (ok. 100 pierwszych znaków z treści zadania)
   • Data wykonania
   • Od (oznaczenie osoby, która zleciła zadanie)
   • Dla (oznaczenie osoby, dla której zlecone jest zadanie)
6. Lista zadań może być filtrowana wg następujących kryteriów:
   • Stan (aktualne, archiwalne)
   • Data wykonania (filtr wyłączony lub określona data)
   • Tytuł/treść (wpisanie frazy, która będzie jednocześnie wyszukiwania w tytule i treści zadania)
   • Przypisane do (wybór z listy osób) – do kogo zadanie jest przypisane
   • Przypisane od (wybór z listy osób) – od kogo pochodzi zadanie
7. Lista zadań powinna mieć możliwość wydruku – z uwzględnieniem filtrowania
8. Użytkownik powinien mieć możliwość podglądu szczegółów zadania – w odrębnym oknie.
9. Użytkownik powinien mieć możliwość zmiany statusu zadania na:
   • Zrealizowane
   • Zakończone bez realizacji
10. Nie można zmienić statusu zadania ze zrealizowanego lub zakończonego bez realizacji na aktywny.
11. Zadania mogą być edytowane wyłącznie przez jego autora
12. Użytkownicy powinni móc logować się do aplikacji przy użyciu nazwy użytkownika i hasła. Dane te są nadawane przez administratora systemu.
13. Użytkownik może sortować listę wg dowolnej z wyświetlanych kolumn
14. Użytkownik może dowolnie zmieniać kolejność kolumn
15. Aplikacja powinna zapamiętywać ostatnio wybrany przez użytkownika wygląd listy (kolejność oraz posortowanie kolumn)

Skoro wiemy już, jakie są oczekiwania użytkownika co do systemu – możemy przystąpić do wstępnego projektu. To już w następnym odcinku.

Przypomnę tylko o zaproszeniu do współpracy, zawartym w poprzednim wpisie.

Powiązane wpisy:

1. Wielopoziomowa aplikacja – nauka przez przykład

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Tyle tytułem nudnego wstępu, przejdźmy do konkretów. Z racji tego, że przez zasiedzenie w technologiach webowych ominęło mnie WPF – postanowiłem wykorzystać właśnie tę technologię przy realizacji projektu. Godne zainteresowania jest również Windows Communication Foundation – czyli WCF. Jeśli chodzi o dostęp do danych przyznam, że wybór jest trudny. Używam i pokochałem NHibernate ale przy chęci nauki nowych narzędzi mocno kusi Entity Framework 4, który jest już na tyle dojrzały, że warto się nim zainteresować.

Pewnie zastanawiacie się co to za projekt, który determinowany jest technologiami. Jak widać jest tutaj trochę odwrotna sytuacja – „dobieram” projekt do tego, czego chciałbym się nauczyć. Blog będzie dziennikiem, opisem napotykanych problemów, miejscem na Waszą krytykę podejmowanych działań.

Tutaj właśnie dochodzę do sedna sprawy. Przedzieranie się przez tyle nowych rzeczy może okazać się dość trudne przy ograniczonych zasobach czasowych (praca na pełny etat). Może więc znajdzie się czytelnik (dwóch?) chętnych do wspólnej nauki i prowadzenia projektu. Mam tutaj na myśli połączenie sił i konkretne podejście do tematu – bez kompromisów. Poligon z ostrą amunicją.

Przygotuję serię opowieści użytkownika pozwalających na opracowanie architektury systemu. Następnym etapem byłaby stopniowa implementacja i publikowanie wyników – np. na CodePlex. Pełny, konkretny i kompletny projekt, którego wynikiem będzie open source’owe oprogramowanie. Publikacja postępów na blogu (tym, który właśnie czytasz lub dedykowanym dla projektu – do wyboru).

Jednak żeby nie przedłużać, podsumujmy:

Cel: Aplikacja do zarządzania zadaniami z wykorzystaniem WPF, WCF, Entity Framework
Założenia: Publikowanie postępów, problemów i wyników kolejnych kroków w formie artykułów na blogu
Potrzebne: 1-2 osoby, chcące uczestniczyć w projekcie. Idealnie, gdyby osoba ta nie znała przynajmniej jednej z wymienionych technologii i aby znała co najmniej jedną z nich

Jeśli kogoś pomysł zainteresuje – zapraszam do kontaktu za pomocą formularza. Zobaczę, czy znajdą się zainteresowani i jak dalej potoczą się losy tego pomysłu.

Powiązane wpisy:

1. Nauka przez przykład – opowieści użytkownika
2. Proste i przyjemne porównanie kolekcji w .NET
3. Mutex i sprawdzanie czy aplikacja jest jedyną uruchomioną

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Utworzenie nowej instancji struktury w tym przypadku:

Okazuje się, że dzięki zastosowaniu jednego z tytułowych bohaterów – operatora implicit – możemy operację uprościć. Do struktury dodajemy kod:

Dzięki czemu możemy już pisać:

co wcześniej zwracało błąd kompilacji „cannot convert source type „int” to target type „SomeStruct”.

Bardzo podobnie sytuacja wygląda w drugą stronę. Dodając operator explicit konwersji na typ int:

możemy rzutować naszą strukturę bezpośrednio na typ int:

O ile w tym trywialnym przypadku zasadność korzystania z operatora explicit jest dyskusyjna, o tyle przy delikatnie bardziej złożonych strukturach można pamiętać o tych dobrodziejstwach.

Nie znaleziono powiązanych wpisów.

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Im dłużej szukałem tym bardziej irytacja narastała. Przypadek ala „Biega, krzyczy pan Hilary: Gdzie są moje okulary?” Pamiętałem, że chodziło o coś w stylu „AllowTabChange”, „AllowFocusChaneOnError” czy inne cudo.

Najbardziej naturalne wydało mi się poszukiwanie we właściwościach samej kontrolki error provider. Oczywiście – nic bardziej mylnego :]

BlinkRate, BlinkStyle.. Nie ma nic pomocnego w rozwiązaniu mojego ogromnego, egzystencjonalnego problemu.
Później zacząłem się przyglądać właściwościom samego TextBoxa… CausingValidation! Nie.. też nie to. Wtedy przestały się odpalać zdarzenia Validating i Validated – w sumie czemu miałoby być inaczej niż mówi opis tej właściwości ;) ?

Nadal uparcie blokował się focus na TextBoxie, jeśli jego zawartość nie spełniała warunków walidacji.. a ja tylko chciałem wypelnić sobie formularz w dowolnej kolejności!

Przyszło oświecenie i zacząłem szukać we właściwościach samej formy.. Wiadomo – im bardziej czegoś się szuka tym bardziej się to ukrywa. Chyba za trzecim razem znalazłem property AutoValidate! Tak – to było to… Oklaski, owacje na stojąco, kurtyna… Zapamiętam już raczej do końca życia ;)

Oj potrafią dać w kość czasem takie głupoty. Człowiek nagle nie wie jak odpytać google’a, by coś sensownego podpowiedział, nikogo znajomego na żadnym komunikatorze. Strach i przerażenie ;)

Też zdarzają się Wam takie małe przeszkadzajki, odbierające więcej energii niż kilka godzin programowania :) ?

Powiązane wpisy:

1. Własny validator w ASP.NET – Date Validator

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

• shallow copy – tzw. płytka kopia. Najczęściej wykonywana przy użyciu metody MemberwiseClone z klasy Object.
• deep copy – tzw. głęboka, pełna kopia. Przyjrzymy się jednej z możliwości jej realizacji – wykorzystania serializacji do strumienia w pamięci.

Zapewne wszyscy wiedzą o istnieniu metody MemberwiseClone w klasie Object.
Pozwala ona na wykonanie tzw. „shallow copy”, czyli „płytkiej kopii” obiektu. Kopia taka nie radzi sobie jednak z typami referencyjnymi zagnieżdżonymi w klonowanym obiekcie. Potrafi poprawnie kopiować tylko Value Types.

Weźmy przykładową klasę Person:

Możemy zaimplementować interfejs ICloneable dla „shallow copy” w ten sposób:

Co się jednak stanie, gdy wykonamy kopię zmiennej kowalski z poniższego przykładu?

Wynik? Tak jak oczekiwaliśmy, Boss w obiekcie kowalski oraz kowalskiCopy wskazują na ten sam obiekt – jankowski.

Jak widać nie jest to idealne wyjście. Rzadko zdarza się, by obiekt zawierał wyłącznie value types. Ponadto metodę MemberwiseClone możemy wywołać tylko w klasie, do której mamy dostęp. Dlaczego? Ponieważ jest ona oznaczona jako protected w klasie Object. Oznacza to, że nie użyjemy jej, gdy chcemy sklonować typ z innej biblioteki, której źródła nie jesteśmy w stanie sami zmodyfikować implementując ICloneable.

Właśnie tutaj z pomocą przychodzi nam serializacja. Wystarczy zserializować obiekt do strumienia w pamięci i zdeserializować do innej instancji. Gotowe.

Jak z realizacją?
Nic nie stoi na przeszkodze, aby zamknąć kod w statycznej metodzie i wykorzystać typ generyczny. Dzięki temu będziemy mogli przy użyciu jednej metody serializować wszystkie typy! No – prawie wszystkie.

Należy pamiętać, że typ, który chcemy serializować:

• musi być oznaczony atrybutem Serializable
• wszystkie jego pola muszą być serializowalne

Jeśli klasa nie będzie spełniać powyższych wymagań, w runtime otrzymamy SerializationException.

Do naszej klasy wprowadzamy więc małą modyfikację:

Metoda, którą będziemy serializować nasze obiekty jest dość prosta.

W dyrektywie using tworzymy nowy MemoryStream. Następnie tworzymy instancję BinaryFormattera, informując go w konstruktorze, że będzie użyty w kontekście serializacji.
Serializujemy przekazany obiekt, przewijamy stream do początku i deserializujemy. Musimy przeprowadzić rzutowanie (Deserialize zwraca Object). Trochę kodu:

To wszystko. Przykład użycia:

Efekt wykonania tej metody? W oknie output pojawi się false. Oznacza to, że obiekt został w pełni sklonowany – łącznie z referencją do szefa.

Jest jeszcze kilka niewielkich niuansów związanych z serializacją – jak np. delegaty czy propertiesy, które nie powinny być serializowalne. To jednak materiał na odrębny, obszerny wpis.

Powiązane wpisy:

1. Show-hide JavaScript – proste podłączenie przy użyciu C#

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Przeważnie ustawiałem jeden projekt jako startowy korzystając z opcji w menu kontekstowym na projekcie: „Set as startup project”.

Możliwe jest jednak ustawienie wielu projektów jako startowych. W tym celu należy wywołać menu kontekstowe na Solution i wybrać Properties:

Naszym oczom ukaże się okno właściwości. Wybieramy po lewej opcję Common Properties -> Startup Project.
Teraz wystarczy przełączyć je w tryb „Multiple startup projects” i wybrać akcję na tych projektach, które nas interesują:

Można ustawić projekt w trybie:

• None – wiadomo ;)
• Start – uruchamia z debuggerem
• Start without debugging – wiadomo ;)

Także.. happy debugging! ;)

Powiązane wpisy:

1. The Web Application is configured to use IIS. The IIS Web server is not installed on this computer.
2. Wielopoziomowa aplikacja – nauka przez przykład

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Otóż co to za właściwość? Tatusiem Mutexu jest bezpośrednio windowsowy kernel a jego właścicielem może być w jednej chwili tylko jeden wątek. Wątek, który przejmuje obiekt typu Mutex na własność nie blokuje sam siebie ale musi zwolnić go przy użyciu metody ReleaseMutex. Co w tym nadzwyczajnego? Jeszcze jedna sztuczka!

Korzystając z jednego z przeciążonych konstruktorów, możemy nadać obiektowi typu Mutex nazwę. Uwaga, kurtyna w górę ;) Nazwa ta jest unikalna wśród wszystkich procesów w systemie! Otóż to, panie i panowie ;) Całe to cudeńko pozwala nam niejako udostępniać obiekt Mutex pomiędzy różnymi aplikacjami. Przeważnie użylibyśmy tej właściwości do synchronizacji dostępu tych aplikacji np. do zasobów dyskowych, sieciowych itp. Jednak jest jeszcze jedno interesujące użycie.

Do sedna. Wykorzystując konstruktor z trzema parametrami:

Możemy skonstruować sprytny kod, który pozwoli uruchomić jednocześnie tylko jedną instancję pisanej przez nas aplikacji. Przykład?

W sumie jedną linijką kodu załatwiamy sprawdzenie. Być może nie jest to wyjście idealne, ale czasem może uratować trochę czasu.

Powiązane wpisy:

1. Wielopoziomowa aplikacja – nauka przez przykład
2. „throw” czy „throw exc” – czyli jak najlepiej przerzucić wyjątek wyżej
3. Shallow copy a deep copy – klonowanie obiektu z MemberwiseClone oraz przy użyciu serializacji

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Na wstępie „krótkie” wprowadzenie – opis książki, którą męczyłem przez ostatnie ładnych „kilka” dni ;)

Co uważniejsi z czytelników zauważyli malutki widget po prawej stronie – „Obecnie czytam”. Właśnie wymieniła się w niej książka. Skończyłem czytać „CLR VIA C#” Richtera, zabieram się za „VISUAL C# 2005: THE BASE CLASS LIBRARY” Balena. Z tą książką powinno pójść łatwiej i szybciej niż z Richterem (takie mam wrażenie).

CLR VIA C# jest bardzo interesującą pozycją, którą polecam każdemu. Richter w dość swoisty sposób rozebrał na części pierwsze wszystko, z czym spotykamy się na co dzień. Pierwsza część jest mocno teoretyczna – operacja na otwartym sercu .NET, czyli CLR właśnie. Ciekawostki, ogólny zarys i założenia, które zapadają w pamięć i sporo rozjaśniają. Część „Working with types” – dość ciekawa. Nie zanudza, mimo, iż opisuje rzeczy oczywiste. „Designing parts” – wspaniałe kompendium dla każdego, kto programuje współdzielone komponenty lub po prostu dąży do tego, by jego kod był zgodny ze standardem, skalowalny, bezpieczny i zoptymalizowany. 70 stron czyta się z miłym odczuciem, że nareszcie ktoś uporządkował to nad czym zawsze zastanawiałem się „czy robię to dobrze?”.

Dział „Essential types” również segreguje i porządkuje zagadnienia dotyczące rzeczy, z którymi spotykami się często. Praca z tekstem, typami enumerowanymi, tablicami, interfejsami, typami generycznymi – po lekturze staje się bardziej przewidywalna i pewna. Same przykłady są naprawdę w porządku. Prezentują często wiele aspektów poruszanego zagadnienia w przystępny sposób. Nie traktują czytelnika jako „niepełnosprytnego” wyjaśniając niepotrzebnie każdą linijkę – oby takie przykłady spotykać w każdej książce.

Sekcja „CLR Facilities” nie jest lekka ale jest niesamowicie przydatna. Świadomość istnienia i sposób działania Garbage Collectora, refleksje i operacje asynchroniczne – nie taki wilk straszny, jak go malują.

Książki tej (niemal 650 stron) nie da się przeczytać i zapamiętać wszystkiego. Nie raz jednak wracam do niej podczas codziennej pracy, utrwalając coś, co w danej chwili robię. Sama świadomość, że wiadomo gdzie zajrzeć aby uzyskać pewną podpowiedź czy wskazówkę jest komfortowa. Książka to kompendium, które zwraca uwagę na aspekty często traktowane w innych publikacjach po macoszemu lub wręcz pomijane. „Important notes” – przyciągają uwagę do pułapek, na których można się wyłożyć przy nieumiejętnym używaniu tego, co oferuje C#. Jednocześnie książkę czyta się przyjemnie. Liczne wzmianki o tym, że Microsoft (zdaniem autora) coś schrzanił i ma nadzieję, że naprawią to w następnej wersji przyprawiają o uśmiech i zwracają uwagę na to, że nikt nie jest nieomylny ;) Richter ma co prawda świra na punkcie thread safety, security, wydajności, zasięgu widoczności zmiennych, pieczętowania klas – i trochę tym zaraża ;) To w sumie jedyny zarzut do książki ;)

Jeden z przykładów, gdy sedno będzie krótsze niż wstęp ;) Po przeczytaniu „THE BCL” zastanawiam się nad połknięciem pozycji stricte „egzaminowej” i podejście do MCTS. Propozycja szefostwa i własne obserwacje to 70-536: Microsoft .NET Framework – Application Development Foundation. Ktoś z Was miał sposobność zdawać? Jak poszło? Jak się przygotowywaliście? Ile czasu Wam to zajęło? Może ktoś, tak jak ja, dopiero planuje? Czy według Was obecnie takie potwierdzenie umiejętności – poza własną satysfakcją – jest przydatne?

Zapraszam do dyskusji w komentarzach. Myślę, że pomoże to i mi rozwiać niektóre wątpliwości.
Jeśli ktoś chce podzielić się informacją o ciekawej książce (niekoniecznie w tematyce egzaminowej) – również chętnie zapoznam się z Waszym „co czytam”.

Powiązane wpisy:

1. Shallow copy a deep copy – klonowanie obiektu z MemberwiseClone oraz przy użyciu serializacji

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Pewnie nie raz staliście przed sytuacją, w której jakaś z funkcji spowodować może powstanie wyjątku, którego wystąpienie trzeba zalogować i przerzucić go dalej (re-throw), aby aplikacja zajęła się nim jak należy. Jednocześnie idealnie, gdy wyjątek zawierał będzie jak najwięcej informacji. Zalicza się do nich przyjaciel każdego programisty – StackTrace.

Rozpatrzmy poniższy kod:

Czyli testowa klasa, której metodę SomeTestPublicMethod udostępniamy jako publiczną, ona natomiast wywołuje prywatną metodę SomeMethod – rzucającą wyjątek ApplicationException.
Jak widać wystąpienie wyjątku chcemy zalogować w metodzie SomeTestPublicMethod i rzucić wyjątek dalej. Kod wykonujący nasz „błędny” program:

Czego spodziewacie się w StackTrace? Czy zaprowadzi nas ona do oryginalnej metody SomeMethod, która spowodowała błąd? Otóż niestety nie, StackTrace wygląda tak:

Niepełny StackTrace

Zauważcie, że Message jest w porządku – pochodzi z oryginalnie rzuconego wyjątku. Dokładna informacja o linii wskazuje jednak dopiero na miejsce, w którym napisaliśmy „throw exc;” – czyli SomeTestPublicMethod. Może wydawać się to nieistotne, bez debugowania ciężko byłoby jednak odgadnąć w czym problem i gdzie on tak naprawdę powstaje.
Zamieńmy dosłownie jedną linię – zamiast „throw exc” zróbmy „throw”. Efekt?

Kompletny StackTrace

Różnica? Bogatszy StackTrace wskazujący na oryginalne miejsce powstania błędu – czyli prywatną metodę SomeMethod. Być może zagadnienie niektórym wydaje się trywialne, ale pamiętajcie – jeśli chcecie po prostu „pchnąć” wyjątek dalej, bez utraty informacji (ani opakowania go we własną klasę wyjątku – np. przekazując jako InnerException) używajcie samego „throw”. Oszczędzić może trochę pracy w przyszłości ;)

Powiązane wpisy:

1. Mutex i sprawdzanie czy aplikacja jest jedyną uruchomioną

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

W przedostatnim wpisie, poruszyłem temat napisania własnego walidatora do daty. Dziś napotkałem na podobny problem – walidacja kontrokli CheckBoxList pod kątem zaznaczenia przynajmniej jednej wartości. Jakieś było moje zaskoczenie ;-) gdy okazało się, że żadna z domyślnych kontrolek walidatorów nie potrafi tego niezmiernie skomplikowanego zadania wykonać ;-) Oczywiście można to załatwić banalnie: CustomValidator i odpowiednia prosta funkcja. Gdzie jednak ponowne wykorzystanie kodu – tak przecież przez nas wszystkich lubiane :) W kolejnym projekcie, na kolejnej stronie – nie będziemy przecież kopiować kodu.

W związku z tym, że większość kodu dla walidatorów jest wspólna (różnią się tylko funkcją EvaluateIsValid oraz kodem JS) nie będę zbyt mocno się rozpisywał. Oto kod:

Wszystko wygląda standardowo:

• ControlPropertiesValid – sprawdzamy, czy kontrolka, której ID trzyma property ControlToValidate jest rzeczywiście kontrolką typu CheckBoxList
• EvaluateIsValid – sprawdzamy, czy jakikolwiek element został zaznaczony
• OnPreRender – podłączamy nasz kod do walidacji po stronie klienta

Kod do walidacji CheckBoxLista po stronie klienta również nie jest zbyt skomplikowany. CheckBoxList jest renderowany jako tabelka, w której komórki są zestawem: input typu checkbox + label z atrybutem for. Wystarczy więc pętlą „przelecieć” po wszystkich elementach tabelki typu checkbox i sprawdzić, czy którykolwiek z nich jest zaznaczony.

CheckBoxList renderowany jako tabelka

Gotowe. Nasz skrypt podłączamy tak jako ostatnio – w zasobach, rejestrując go w pliku AssemblyInfo.cs, w folderze Properties projektu. Jednocześnie oczywiście nie zapominamy o ustawieniu we właściwościah naszego pliku Build Action na Embedded Resource ;)

Demo:
asp.andrzej.net.pl

Kod do pobrania:
Note: There is a file embedded within this post, please visit this post to download the file.

Powiązane wpisy:

1. Własny validator w ASP.NET – Date Validator
2. Show-hide JavaScript – proste podłączenie przy użyciu C#

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.