PAWEŁ STREJCZEK

Przygotowywałem ostatnio dla klienta soft, którego zadaniem było pobieranie i wyświetlanie (z opcjami filtrowania) plików CSV generowanych przez aplikacje pilnujące produkcji.

Zadanie dość banalne, nie mniej jednak pojawił się drobny problem – nowy plik CSV tworzony jest jedynie po zmianie asortymentu na maszynie co nie zdarza się mimo wszystko tak bardzo często, a użytkownik chce mieć dostęp do wszystkich zarejestrowanych danych. Istnieje w związku z tym spore niebezpieczeństwo, że pojawi się klasyczny problem potrzeby jednoczesnego dostępu do pliku zarówno przez soft zapisujący jak i odczytujący.

Z pomocą przychodzi tutaj wykorzystanie klasy FileStream – koniecznie zarówno w aplikacji odczytującej jak i zapisującej. Możemy tutaj zdefiniować parametry blokowania otwartego przez nas pliku dla innych aplikacji próbujących tego samego.

Przykład jest w VB.net. Co prawda na codzień używam bardziej C# ale w tym projekcie są akurat takie wymagania klienta.

Dim iStream = New FileStream(filename, FileMode.Open, FileAccess.Read, FileShare.ReadWrite)

Strumień z przykładu sparametryzowany jest do odczytu ale zezwalając na odczyt i zapis innym. Taki strumień możemy potem np. użyć jako parametr dla StreamReader-a

Dim sr As StreamReader = New StreamReader(iStream, System.Text.Encoding.UTF8)

Szczegóły dostępnych opcji inicjalizacji obiektu klasy FileStream są oczywiście na MSDN
http://msdn.microsoft.com/pl-pl/library/system.io.filestream(v=vs.110).aspx

Dzisiaj uruchamialiśmy u klienta aktualizację systemu, do którego aplikację pisałem jeszcze w 2008 roku. Sześć lat to jednak szmat czasu i poza dość starą technologią, której już dzisiaj w zasadzie nie używam (Delphi 2005) sam kod pozostawia niestety też wiele do życzenia, a z praktyki wiem, że refaktoryzacja bez możliwości dobrego zasymulowania warunków produkcyjnych zwykle przynosi więcej problemów na obiekcie niż zysku. Generalnie chyba nie jest źle – ponoć jak programista widzi swój kod napisany chwilę temu i nie ma do niego żadnych zastrzeżeń to oznacza, że się nie rozwija …

Jednak nie o tym chciałem. Jak się okazuje – nawet mając całkiem spore mniemanie o własnych umiejętnościach łatwo wpaść w pułapkę. Z pozoru prosta funkcja, która wyświetla odczytane z pliku dane przepisane tam wcześniej z bazy (MS SQLServer) przez inną funkcję – powodowała najpierw zerwanie połączenia  z bazą w innej funkcji (pomimo tego, że opisywana funkcja nie korzysta z tej komunikacji) a potem raportowany przez kompilator Access Violation Error z nic nie mówiącą wartością adresu w pamięci.

Ponad dwie godziny zajęło mi zdiagnozowanie problemu, którym okazało się zapisywanie tablicy poza zadeklarowany wymiar. Prawdopodobnie podczas nawykowego używania skrótów klawiszowych przełączył mi się tryb klawiatury po czym musiałem niechcący skasować kawałek kodu i zamiast zrobić Undo – poprawiłem tak jak mi się wydawało że było wcześniej, nie sprawdzając uprzednio deklaracji tablicy.

Szkolny błąd – należało by się po tym najpierw ubiczować a potem oddać fartucha, ale jak mówią „Errare humanum est” i niestety w stresowych warunkach na instalacji u klienta takie rzeczy czasem potrafią umknąć – ot proza programistycznego życia.

Dzisiaj pół dnia spędziłem walcząc z ustawieniem validacji dla kontrolek w wpf. Zdefiniowałem mapowanie do klasy, wskazałem na właściwą klasę i g..no – wynikiem builda za każdym razem był Error i komunikat o nie możliwości znalezienia mojego validationrule w mapowanej klasie.

W pewnym momencie z głupia skasowałem całą linijkę i wpisałem jeszcze raz, pozwalając tym razem na uzupełnienie jej z intellisense – i nagle cudownie zadziałało ! przy czym „podopowiedziany” tekst w niczym nie różnił się od wprowadzonego wcześniej ręcznie (jeszcze zanim zdefiniowałem regułę).

Damn you Visual Studio !