I TY możesz pomóc wybrać nazwę dla nowej wersji Eclipse'a!

Zbliżamy się powoli do końcowego odliczania przed oficjalnym wydaniem Eclipse 3.5 Galileo, a niedługo potem zaczną się prace nad kolejną wersją, tym razem Eclipse 3.6 ??? - no właśnie, ciągle nie ma nazwy dla kolejnej wersji Eclipse'a! Jeśli chcesz pomóc w wyborze nazwy oddaj swój głos w ankiecie lub weż udział w dyskusji. Do tej pory nazwy związane były z księżycami Jowisza oraz z ich odkrywcą, ale nikt nie powiedział, że tak musi być nadal, zatem do głosowania!

Domyślne edytory plików

Pewnie każdemu z nas zdarza się mieć w projekcie pliki, które chcemy otwierać zawsze w naszym ulubionym edytorze (niekoniecznie tym z Eclipse'a), a Eclipse uparcie otwiera nam je domyślnym edytorze. Co wtedy robimy? Klikamy w widoku Package Explorer prawym przyciskiem myszy na pliku i wybieramy Open with->Nazwa edytora.

A co powinniśmy zrobić?

Otworzyć preferencje (Window->Preferences) na stronę General->Editors->File Associations:

Możemy tutaj zdefiniować jaki edytor powinien być domyślny dla naszego typu pliku.

Typy plików definiujemy w górnej sekcji File Types. Co istotne możemy też zdefiniować tutaj konkretny plik, a nie tylko typ!

Aby połączyć pliki z edytorem wystarczy w sekcji File Types zaznaczyć nasz plik lub typ plików i w sekcji Associated Editors kliknąć przycisk Add i podać wybrany przez nas edytor - mamy do wyboru edytory dostępne w Eclipse jak i programy zewnętrzne, więc możemy dostosować Eclipse'a do naszych potrzeb.

O debugowaniu część III

No i znowu minął ponad miesiąc bez nowości, ale oto jestem z garścią kolejnych informacji na temat mechanizmu debugowania w Eclipsie.

W poprzednim poście mówiliśmy o właściwościach punktów wstrzymań, spójrzmy teraz jak można sprawnie nimi zarządzać - służy do tego widok Breakpoints (Window->Show View->Other->Debug->Breakpoints):

W widoku tym możemy w prosty sposób za pomocą opcji w pasku narzędzi:

• dodawać i usuwać punkty wstrzymań (pojedynczo lub wszystkie za jednym razem)
• wyświetlić tylko punkty wstrzymań aktywne dla wybranej platformy docelowej (np. dla debugowania kodu w C, Javie lub dla skryptów Anta widoczne będą tylko punkty wstrzymań danego typu)
• przejść do miejsca w kodzie, w którym punkt dany punkt wstrzymań jest ustawiony
• deaktywować wszystkie punkty wstrzymań
• dodać punkt wstrzymań wyjątków

Natomiast gdy wejdziemy w menu widoku

będziemy mogli:

• grupować punkty wstrzymań
• definiować zbioru robocze punktów wstrzymań
• pokazywać nazwy kwalifikowane

Jeśli chcemy podzielić się z kimś naszym zbiorem punktów wstrzymań to powinniśmy zainteresować się opcją ich eksportu File->Export->Run/Debug->Breakpoints i importu File->Import->Run/Debug->Breakpoints.

O debugowaniu część II

W poprzednim poście mówiliśmy o różnych typach punktów wstrzymań (ang. breakpoints), dzisiaj proponuję spojrzeń na ich ciekawe właściwości, które mogą zwiększyć naszą wydajność przy szukaniu błędów.

Żeby dostać się do właściwości punktu wstrzymań wystarczy kliknąć na nim (na lewym bocznym pasku edytora, lub też w widoku Breakpoints) prawym przyciskiem myszy i wybrać opcję Breakpoint Properites.

Hit Count

W polu Hit Count podajemy wartość całkowitą dodatnią N, co spowoduje, że punkt wstrzymań będzie aktywny, gdy wykonanie programu trafi na niego N-ty raz.

Żeby lepiej to zobrazować spójrzmy na przykład poniżej. Załóżmy, że mamy następujący kod z ustawionym punktem wstrzymań: 

wartość właściwości Hit Count dla punktu wstrzymań ustawiamy na 7 i uruchamiamy debugowanie. Do momenty zatrzymania się na punkcie wstrzymań na konsoli zobaczymy:

czyli kod wykonał się sześć razy i gdy po raz siódmy trafił na punkt wstrzymań zatrzymał swoje wykonywanie.

Warunki (ang. Conditions)

Właściwość ta daje nam możliwość ustawiania (jak sama nazwa wskazuje) warunków, po spełnieniu których nasz punkt wstrzymań będzie aktywny i zatrzyma wykonywanie programu. Kiedy może się to przydać? Wyobraźcie sobie, że macie jakąś pętlę, w której wykonujecie operacje na 1000-elementowej liście i dla kilku elementów pętla działa niepoprawnie. Można sobie z tym poradzić ustawiając odpowiednie instrukcje warunkowe w pętli i dla tych instrukcji ustawić punkty wstrzymań, ale takie rozwiązanie powoduje, że w naszym kodzie pojawia się niepotrzebny bałagan. Lepiej do takich celów wykorzystać właśnie Warunki.

Weźmy kod z wcześniejszego przykładu i ustawmy następnujący warunek na punkcie wstrzymań:

Po uruchomieniu programu w trybie debugowania na konsoli zobaczymy:

Przy konstrukcji warunku możemy korzystać ze wszystkich zmiennych dostępnych w obrębie kontekstu danego punktu wstrzymań. W polu do wpisywania Warunku działa również Content Assist, więc można korzystać z podpowiedzi dostępnych pod skrótem Ctrl+Space.

O debugowaniu część I

Trochę długo nic nowego się nie pojawiało, czas to zmienić. Na innym blogu, na którym się udzielam rozpocząłem jakiś czas temu serię postów na temat eclipsowego debuggera. W pewnym momencie Jacek Laskowski zwrócił moją uwagę na fakt, że brakuje takich informacji w języku polskim, więc postanowiłem również tutaj napisać kilka postów na temat debuggera, którego możecie znaleźć w Eclipsie.

Pewnie powinienem zacząć od tego w jaki sposób uruchamiać aplikację w trybie debug, ale żeby na samym początku nikogo nie zanudzić i jednocześnie, żeby nie było za trudno zacznijmy może od przeglądu dostępnych w Eclipsie typów punktów wstrzymań (ang. breakepoints).

Podczas debugowania możemy korzystać z:

• punktów wstrzymań linii
• punktów wstrzymań metod
• punktów wstrzymań pól
• punktów wstrzymań klasy
• punktów wstrzymań wyjątków

Punkty wstrzymań linii

Jest to chyba najpopularniejszy rodzaj punktów wstrzymań, sam kiedyś korzystałem jedynie z nich, dlatego też nie ma chyba potrzeby, żeby wchodzić w szczegóły. Takie punkty wstrzymań ustawiamy (klikając na lewym bocznym pasku edytora przy odpowiedniej linii) jeśli chcemy, aby wykonywanie naszego programu zatrzymało się na konkretnej linii.

Punkty wstrzymań metod

Czasami może nas interesować sytuacja, kiedy program wchodzi i/lub wychodzi z jakiejś metody, wówczas przydatne stają się punkty wstrzymań metod. Punkty takie ustawiamy klikając na lewym bocznym pasku edytora przy linii z rozpoczęciem definicji metody

We właściwościach (klikamy prawym przyciskiem na ikonce punkty wstrzymań i wybieramy Breakpoints Properties) takich punktów wstrzymań możemy określić czy program ma się zatrzymać na wejściu i/lub wyjściu z metody:

Punkty wstrzymań pól

Jeśli zależy nam na zatrzymaniu wykonywania programu, gdy określone pole klasy jest wykorzystywane (odczytywane i/lub modyfikowane) to możemy wykorzystać punkty wstrzymań pól.

Tutaj również właściwości pozwalają nam dostosować zachowanie punktu wstrzymań do naszych potrzeb - możemy wybrać, czy ma on być aktywny przy odczycie i/lub modyfikacji danego pola:

Punkty wstrzymań klas

Tego rodzaju punktu wstrzymań możemy wykorzystać, gdy interesuje nas moment, w którym dana klasa jest po raz pierwszy ładowana przez maszynę wirtualną.

Punkty wstrzymań wyjątków

A co jeżeli w naszej aplikacji rzucany jest jakiś wyjątek i ciężko jest nam znaleźć miejsce i przyczynę takiej sytuacji? Wystarczy wtedy użyć punktów wstrzymań wyjątków. Wyjątki takie ustawia się w widoku Breakpoints (Window->Show View->Other->Debug->Breakpoints) - wybieramy opcję Add Java Exception Breakpoint:

i w nowym oknie wybieramy wyjątek, na który chcemy reagować:

Dodatkowo we właściwościach (w widoku Breakpoints klikamy prawym przyciskiem na danym wyjątku i wybieramy Breakpoint Properties) możemy wskazać, czy program ma się zatrzymać na wyjątkach "łapanych", "niełapanych", czy może na również na podklasach danego wyjątku:

W kolejnym poście spojrzymy jakie jeszcze możliwości dają nam punkty wstrzymań.

3. edycja Eclipse DemoCamp Poznań już w poniedziałek!

Zapraszamy na 3. edycję Eclipse DemoCamp Poznań - cyklu imprez odbywających się na całym świecie pod patronatem Eclipse Foundation. Spotykamy się w poniedziałek, 24 listopada w Piwnicy 21 w Poznaniu. Start o 18:00.

Będziemy promować Eclipse'a jako IDE oraz platformę RCP tym razem jednak przygotowaliśmy dla Was coś wyjątkowego! Prosto z Kanady zaprosiliśmy Wassima Melhema - lidera technicznego zespołu tworzącego Eclipse Plug-in Development Environment (PDE), obecnie rozwijającego komercyjne produkty bazodanowe w oparciu o platformę Eclipse. Dawid Weiss z Politechniki Poznańskiej opowie o kulisach osadzania wyszukiwarki Carrot w aplikacji RCP, zaś Bartosz Michalik przedstawi sposób na niechciane rozszerzenia platformy, prezentując mechanizm PDE Product Customization.

Zachęcamy i Was do współtworzenia imprezy w sesji lightning talks, która ostatnio cieszyła się dużym zainteresowaniem. Jeżeli chcecie opowiedzieć o Waszym produkcie, doświadczeniach, problemach czy poruszyć jakikolwiek temat związany z Eclipsem - scena, mikrofon i projektor staną się Wasze na kilka minut.

Tak jak uprzednio przygotujcie się na ożywione dyskusje przy darmowym piwie i pizzy oraz na odrobinę aktywności fizycznej na matach DDR ;-) A wszystko to w znakomitym towarzystwie poznańskiej społeczności IT!

Udział jest bezpłatny jednak prosimy o rejestracje na stronie (lub mailowo u organizatorów) .

Czas na małe podsumowanie

Ponad rok temu (a dokładniej 7. października) pojawił się pierwszy post na tym blogu, pora zrobić małe podsumowanie. Muszę przyznać, że gdy zaczynałem swoje własne blogowanie (jestem też współautorem bloga eclipser-blog) nie miałem pojęcia, czy ktokolwiek będzie chciał, czytać moje porady i przemyślenia...po roku jednak okazuje się, że kilka osób tutaj zajrzało, a niektórzy zaglądają nawet dość regularnie.
A co mówią o moim blogu liczby?

• Powstało 71 (łącznie z tym) postów.
• Pojawiły się 52 komentarze (przy okazji dziękuję wszystkim za ich komentarze - cieszy, gdy widać, że ktoś to czyta i znajduje chwilę, żeby zostawić coś od siebie).
• Najwięcej postów pojawiło się zaraz po założeniu bloga (czyli w październiku 2007) -10 postów, ale w sierpniu 2008 też nie próżnowałem - 9 postów.
  
• Najbardziej leniwy byłem w maju i wrześniu tego roku, kiedy to pojawiło się wtedy po jednym wpisie.
• 3 razy zmieniałem szatę graficzną.
• Google Analitycs twierdzi, że:
  
  • na blogu było 11 547 odwiedzin
  • strony bloga pokazano 20 886 razy
  • czytelnicy pochodzili z 43 krajów (najwięcej oczywiście było z Polski)
  • jak na stolicę przystało, to właśnie z Warszawiacy najczęściej odwiedzali bloga
  • najczęściej czytanym postem był post o Mylynie, później o RCP, szukaliście też często informacji, w jaki sposób instalować wtyczki
• FeedBurner mówi, że:
  
  • 94 osoby są zapisane do subskrypcji kanału RSS
  • kanał RSS jest wykorzystywane przez kanał z java.pl
    

To chyba na tyle tych statystyk. Dziękuję wszystkim, którzy przez ten rok chcieli mnie czytać i zapraszam do dalszego obserwowania bloga - obiecuję (w miarę) regularną aktywność :)

Jak korzystać z filtrów?

Pamiętam jak bardzo byłem zdziwiony i zadowolony, gdy po raz pierwszy odkryłem, że widok Package Explorer daje możliwość filtrowania swojej zawartości - niby taka mała rzecz, a ucieszyła mnie niezmiernie. O czym mówię? Kiedy wejdziemy sobie do menu widoku znajdziemy tam opcję Filters...
Gdy wybierzemy właśnie tę opcję pojawi nam się okienko z możliwościami filtrowania zawartości widoku pod różnym kątem:
Jak widzimy mamy sporo elementów, które możemy ukryć, np. zamknięte projekty (ang. Closed projects), puste pakiety (ang. Empty packages), elementy nie-javowe (ang. Non-java elements) i wiele innych. Możemy też stworzyć swój własny filtr, nadając mu nazwę oraz podając pliki o jakich rozszerzeniach powinny być ukryte.
Z filtrów należy jednak korzystać ostrożnie, bo po jakimś czasie możemy zapomnieć, że jakiś element ukryliśmy i będziemy go usilnie szukać nie mając pojęcia, że wystarczy odznaczyć, którąś z opcji w filtrach, aby go zobaczyć ponownie.

Filtrowanie zawartości to domena nie tylko widoku Package Explorer, inne widoki też często dają takie możliwości (np. Outline), jednak czasami kryją się one pod mniej intuicyjną nazwą - np. w widoku Problems znajdziemy opcję Configure Content...:
po wybraniu której pokaże nam się miej więcej takie okno:

W oknie tym możemy:

• określić błędy jakiego typu mają się wyświetlać (np. błędy kompilacji, błędy wtyczek, itp.)
  
• wskazać jaki tekst mają zawierać opisy błędów, które mają się pojawiać w widoku
• określić jakiego rodzaju informacje mają być wyświetlane (błędy - ang. errors, ostrzeżenia - ang. warnings czy informacje - ang. info)
• wskazać, których elementów problemy mają być brane pod uwagę (np. opcja On selected element and its children pozwala na wyświetlanie błędów z całego jednego konkretnego projektu zaznaczonego w widoku Package Explorer)
• dodawać własne konfiguracje zawartości, zapisywać je i później w łatwy sposób się między nimi przełączać

Polecam korzystanie w filtrów, gdyż potrafią one ukryć sporo niepotrzebnych w danej chwili informacji, a co za tym idzie w znaczny sposób przyspieszyć naszą pracę.