Press "Enter" to skip to content

„Czytaj komunikaty” – czyli dlaczego warto patrzeć automatom IDE na ręce.

Zacznę może od opisania problemu jaki miałam wczoraj w pracy. Ładuję sobie z bazki dane (acz ich źródło jest w tym momencie tak istotne jak skład obecnego parlamentu, czyli wcale), aby je po dość banalnej obróbce pokazać użytkownikowi.

Dane wynikowe lądują do ObservableCollection podbindowanej do XamDataGrida. Okazuje się jednak, że jeżeli coś wrzucę do tej kolekcji w konstruktorze, to wszystko gra, ale jak wrzucę ją w OnNavigatedTo lub potem, to elementy trafiają do kolekcji, ale nie pokazują się w widoku, mimo że w analogicznym widoku (żeby nie powiedzieć – żywcem copy-paste z innymi nazwami pól) wszystko działa. No ale tutaj nie działa. Standardowo i po swojemu debuguję wszystko i wydaje się że wszystko gdzie mogę wskoczyć działa jak potrzebuję, wyzywam devów infragistica od tempych ch* jak w kapitanie bombie, skraj wytrzymałości nerwowej skończył mi się jakąś godzinę temu, uderzam do szefa. Szefu – wybitny specjalista który programuje w dotnecie już trzecie stulecie, a w wpfie ze dwie dekady, spędzając ze mną nad problemem kolejne 4 godziny i sprawdzając po swojemu uznaje że problem jest ciekawy i że mam dać mu znać jak coś znajdę, bo on tu nic nie widzi. Wychodzę pośpiesznie z pracy, totalnie załamana. To chyba musi być niewykonywalne, skoro się nie udało nawet Szefowi, który potrafi kilkugodzinny problem w kilka sekund rozwiązać.

Nazajutrz spędzam nad problemem kolejne, nie wiem 4 godziny. Czyli dniówka w plecy na „bo się nie odświeża” (wtedy myślałam jeszcze że problem musi być gdzieś w mechanizmie odświeżania lub rysowania kontrolki, bo przecież dane są) po czym rozwiązuję problem zastanawiając się czy pluć sobie w brodę że doprowadziłam do takiej sytuacji, czy dziwiąc się że taka pierdóła mi tyle czasu zajęła. Diabeł usinga ogonem przykrył.

Tych z syndromem tltr zapraszam na koniec wpisu gdzie jest podane rozwiązanie problemu, a pozostałych zapraszam w dalszą opowieść.

Cofnijmy się ze dwie godziny wcześniej, zanim ten problem wystąpił. Jak mówiłam, podkradłam sobie kawałek widoku, uprzednio kopiując go do vs code, robiąc rename’y, duplikując co trzeba, usuwając co trzeba. Skopiowałam do VS, pogenerowałam z palca nieistniejące propertiesy… no ale kurka w wielu miejscach mi się pogenerowało object, a ja mimo wszystko no chciałam mieć ten właściwy typ – chociażby po to, aby mi powypełniał kolumny prawidłowo (a dwa że nie po to mam silnie typowalny język by wszystko trzymać w object czy dynamic). No to wzięłam pierwszą lepszą propertę z ObservableCollection, przekleiłam do VS Code, zmieniłam nazwę, wkleiłam do kodu tyle razy ile mi było potrzeba zmieniając nazwy propert i fieldów na odpowiednie i ….
Tu mi z niedźwiedzią przysługą przyszedł podpowiadacz, pokazując mi to:

Multiple choices ale się kliknęło

Także kliknęłam i zaufałam że „default” był dobry. Kij że pierwszy raz chyba widzę namespace na oczy. Może nigdy nie zwróciłam uwagi. No traf chciał że koleś sortuje alfabetycznie nie premiując najczęściej używanych. R jest przed S. Bo jak bym rozwinęła to już bym podejrzewam wybrała poprawny;)  To znaczy (uwaga, spoiler) ten na żółto.

Mnie wybierz. Mnieee!

I jakbym tak zrobiła, to problem by w ogóle nie wystąpił.

No ale wystąpił. Jak więc znalazłam rozwiązanie? Uznałam, że coś musiałam pominąć więc patrzę na podobny widok do mojego i porównuję namespace’y. No i był tylko jeden taki, którego nie miałam u siebie, a w tamtym jest.

Był to owy System.Collections.ObjectModel więc go dodałam. Grzecznie z palca wpisałam gdzieś u góry using System.Collections.ObjectModel; i moim oczom ukazało się to.

No weź się zdecyduj, bo gdzie kucharek sześć tam błędy kompilacji

No więc wywalam tego using Remotion.Linq.Collections;, kompiluję, odpalam, działa. Odtańczam taniec zwycięstwa, robię sobie herbatę i biorę się za dopisywanie kolejnych rzeczy.

Co powinno mnie zaniepokoić a zostało olane wcześniej?

Hmm, tu dochodzimy do tytułowego „czytaj komunikaty”. (Tak Nikow- jak zawsze masz rację z tym swoim „bo ty komunikatów nie czytasz”) Bo gdybym miała nawyk ich czytania (a wyzbyłam się go gdzieś na studiach- czując się zbyt pewnie) to już wcześniej bym zauważyła różnicę- przecież te bulby mi się wyświetlały. 

No ale kto to w ogóle czyta? No przecież te zmienne są takie same;) A już na pewno ich typy. Diabeł tkwi w szczegółach.

Patrzyłam na nie nieświadomie setki razy w trakcie analizy – no ale nie na tych szczegółach się skupiałam co trzeba i … mogę mieć coś w polu widzenia a zupełnie tego nie dostrzec – bardziej mnie interesowała aktualna wartość zmiennej – niż jej rzeczywisty typ- jakby to nie miało znaczenia.

Także tępa blondynko – skoro od 3 roku życia umiesz czytać, to znaczy że w wieku prawie 30 tym bardziej. CZYTAJ i sprawdzaj co ci wygenerował automat, bo czasami generuje bzdury. Przecież po zacommitowaniu kodu pojawi się przy nim w chwili blame’a twoje nazwisko, a więc Ty za to odpowiadasz, nie automat, nie twórcy Visual Studio, nie twórcy Resharpera. Ty. Nie płacą ci za bycie małpą i kodzenie na pałę.

Podsumowując, zajęło mi 8 godzin dojście do tego, by zmienić using Remotion.Linq.Collections; na bardziej znany using System.Collections.ObjectModel; Działa? No jak w mordę strzelił. Działa!

I to by było na tyle. Dziękuję za uwagę.

One Comment

  1. „Czytaj komunikaty” – czyli dlaczego warto patrzeć automatom IDE na ręce. – Zagubiona wśród własnych myśli – Piatkosia’s blog

    Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl

Comments are closed.